High bandwidth broadcast system having localized multicast access to broadcast content

ABSTRACT

A method of multicasting digital data to a user accessing an Internet connection is disclosed. The method includes placing digital data that is to be multicast in IP protocol to generate IP digital data. The IP digital data is transmitted from a transmission site to a remote Internet point of presence through a dedicated transmission channel substantially separate from Internet backbone. The dedicated transmission channel may be, for example, a satellite channel. At the remote Internet point of presence, the IP digital data is multicast for delivery to at least one receiving Internet user&#39;s apparatus connected to but distal from the remote Internet point of presence.

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application is a continuation of application Ser. No.09/488,009 (attorney docket No. 3593-12), filed Jan. 20, 2000, which isa continuation of application Ser. No. 08/969,164, filed Nov. 12, 1997,now U.S. Pat. No. 6,101,180. In addition to being related to parentapplication Ser. No. 08/969,164, this continuation case is also relatedto the following continuation application that also claims the benefitof priority from that parent application: Ser. No. ______, (atty docketno. 3593-13), filed Apr. 19, 2000, entitled “High Bandwidth BroadcastSystem Having Localized Multicast Access to Broadcast Content”. Thepresent application also claims priority from related provisionalapplications: U.S. Ser. No. 60/029,427, filed Nov. 12, 1996; U.S. Ser.No. 60/039,672, filed Feb. 28, 1997; and U.S. Ser. No. 60/057,857, filedSep. 2, 1997; all these provisional applications now abandoned.

BACKGROUND OF THE INVENTION

[0002] During the 1970's and 1980's, the defense industry encouraged anddeveloped an interconnecting network of computers as a backup fortransmitting data and messages in the event that established traditionalmethods of communication fails. University mainframe computers werenetworked in the original configurations, with many other sources beingadded as computers became cheaper and more prevalent. With a looseinterconnection of computers hardwired or telephonically connectedacross the country, the defense experts reasoned that many alternativepaths for message transmission would exist at any given time. In theevent that one message path was lost, an alternative message path couldbe established and utilized in its place. Hence, it was the organizedand non-centralized qualities of this communications system which madeit appealing to the military as a backup communication medium. If anyone computer or set of computers was attacked or disconnected, manyother alternative paths could eventually be found and established.

[0003] This interconnection of computers has since been developed byuniversities and businesses into a worldwide network that is presentlyknown as the Internet. The Internet, as configured today, is a publiclyaccessible digital data transmission network which is primarily composedof terrestrial communications facilities. Access to this worldwidenetwork is relatively low cost, and hence, it has become increasinglypopular for such tasks as electronic mailing and weather page browsing.Both such functions are badge or file transfer oriented. Electronicmail, for instance, allows a user to compose a letter and transmit itover the Internet to an electronic destination. For Internet transfers,it s relatively unimportant how long each file transfer takes as long asit is reasonable. The Internet messages are routed, not through a fixedpath, but rather through various interconnected computers until theyhave reached their destination. During heavy message load periods,messages will be held at various internal network computers until thepathways cleared for new transmissions. Accordingly, Internettransmissions are effective, but cannot be relied upon for timesensitive applications.

[0004] Web pages are collections of data including text, audio, video,and interlaced computer programs. Each web page has a specificelectronic site destination which is accessed through a device known asa web server, and can be accessed by anyone through via Internet. Webpage browsing allows a person to inspect the contents of a web page on aremote server to glean various information contained therein, includingfor instance product data, company backgrounds, and other suchinformation which can be digitized. The remote server data is access bya local browser, and the information is displayed as text, graphics,audio, and video.

[0005] The web browsing process, therefore, is a two-way datacommunication between the browsing user, who has a specific electronicaddress or destination, and the web page, which also has a specificelectronic destination. In this mode of operation, as opposed toelectronic mail functions, responsiveness of the network is paramountsince the user expects a quick response to each digital request. Assuch, each browsing user establishes a two-way data communication, whichties up an entire segment of bandwidth on the Internet system.

[0006] Recent developments on the Internet include telephone, videophone, conferencing and broadcasting applications. Each of thesetechnologies places a similar real-time demand on the Internet.Real-time Internet communication involves a constant two-way throughputof data between the users, and the data must be received by each usernearly immediately after its transmission by the other user. However,the original design of the Internet to did not anticipate such real-timedata transmission requirements. As such, these new applications haveserious technical hurdles to overcome in order to become viable.

[0007] Products which place real-time demands on the Internet will beaided by the introduction of an updated hardware interconnectionconfiguration, or backbone,” which provides wider bandwidth transmissioncapabilities. For instance, the MCI backbone was recently upgraded to622 megabytes per second. Regardless of such increased bandwidth, theinterconnection configuration is comprised of various routers which maystill not be fast enough, and can therefore significantly degrade theoverall end-to-end performance of the traffic on the Internet. Moreover,even with a bandwidth capability of 622 megabytes per second, theInternet backbone can maximally carry only the following amounts ofdata: 414—1.5 mbs data streams; 4,859—128 kbs data streams; 21597—28.8kbs data streams; or combinations thereof. While this has anticipated asbeing sufficient by various Internet providers, it will quickly prove tobe inadequate for near-future applications.

[0008] Internal networks, or Intranet sites, might also be used for datatransfer and utilize the same technology as the Internet. Intranets,however, are privately owned and operated and are not accessible by thegeneral public. Message and data traffic in such private networks isgenerally much lower than more crowded public networks. Intranets aretypically much more expensive for connect time, and therefore anyrelated increase in throughput comes at a significantly higher price tothe user.

[0009] To maximize accessibility of certain data, broadcasts of radioshows, sporting events, and the like are currently provided via Internetconnections whereby the broadcast is accessible through a specific webpage connection. However, as detailed above, each web page connectionrequires a high throughput two-way connection through the standardInternet architecture. A given Internet backbone will be quicklyoverburdened with users if the entire set of potential broadcastersacross world began to provide broadcast services via such web pageconnections. Such broadcast methods through the Internet thereby proveto be ineffective given the two-way data throughput needed to access webpages and real-time data.

[0010] Furthermore, broadcasts are typically funded and driven byadvertising concerns. However, a broadcast provided through acentralized location, such as a web page for a real-time Internetconnection, will be limited by practical concerns to offering onlynationally advertised products, such as Coke or Pepsi. Since peoplemight be connected to this web page from around the world, localmerchants would have little incentive to pay to advertise to distantcustomers outside of their marketing area. Local merchants, on the otherhand, would want to inject their local advertising into the datatransmission or broadcasts in such a way not currently available on theInternet.

[0011] There is an enormous demand for the delivery of large amounts ofcontent to a large number of listeners. The broadcast channels of today,such as radio and TV, can only deliver a small number of channels to alarge number of listeners. Their delivery mechanism is well known tocustomers. The broadcaster transmits programs and the listener must tunein” at the proper time and channel to receive the desired show, “OnDemand’ systems have been attempted by the cable industry. Such systemsattempt to transport the program or show from a central repository(server) to the user (client) in response to his/her request. Toinitiate the request, the user selects from a list of candidate programsand requests that the system deliver the selected program.

[0012] The foregoing “on demand’ model of content delivery has placedtwo significant requirements on the delivery system. First, theretypically is a direct connection between each content storage device(server) and each listener (client). The phone system is an example ofsuch a point-to-point interconnection system. Another example of such aninterconnection system is the Internet, which is also largely based onthe terrestrial telecommunications networks. Second, the servertypically seeks to provide the capability of delivering all the programsto the requesting clients at the time that the client demands theprogramming.

[0013] The foregoing requirements can be achieved with limited success,particularly in conjunction with the Internet. The Internet is notsuitable for many types of high bandwidth or on-demand systems. Intoday's Internet, Internet users most often share a terrestrial orperhaps even extra-terrestrial or wireless communicationsinfrastructure; and as a result, the total throughput is limited. Inother words, the Internet is typically a party line shared by a largenumber of users and each subscriber must wait for the line to be freebefore he/she can send data. Since the signal from the server isgenerally a high bandwidth signal including multimedia content, anydegradation of the throughput from the server to the clients results inan annoying disruption of the video and/or audio at the clients.Successful transmission of real-time streaming multimedia content,however, requires sufficient transmission bandwidth between the serverand the client. Since standard IP transmission facilities are a partyline, attempts have been made to impose a quality of service (QOS) intothis dominantly party-line transmission structure. One such QOS featureis the bandwidth reservation protocol called “RSVP.” The RSVP protocolmust be active in each network element along the path from the client tothe server for it to be effective. Until RSVP is fully enabled, QOScannot be guaranteed.

[0014] Once RSVP is fully deployed, then the mechanical process ofreserving bandwidth will be possible to some degree. Nevertheless, evenwith RSVP, the problem remains that the Internet infrastructure provideslimited transmission bandwidth. In this regard, consider the case wherethe sum of all bandwidth reservations exceeds available transmissionbandwidth. To reduce the excessive use of bandwidth reservation,transmission providers anticipate transmission charges based on theamount of bandwidth reserved. This bandwidth charge is not in the spiritof today's free connectivity.

[0015] Another example of the limitations inherent in the finitethroughput of the Internet is the generally limited audience size for agiven transmission link. For example, if there is a 622 megabit/second(mbs) link from an Internet server in New York to a number of clients inLos Angeles and each client requires a separate 28.8 kilobit/sec (kbs)connection to the server, then this link can only support about 22,000clients, a relatively small number of clients when compared to the costof a server capable of supplying the 622 mbs data content. The costsfurther escalate and the client audience size capability furtherdiminishes as each client connects to the server using higher bandwidthmodems or the like. Still further, the same large demand is placed onthe server if each of the 22,000 clients requests the same program butat different times or if each of the clients request a different programat the same, or nearly the same time. The large bandwidth requirements(622 mbs) to supply a relatively small number of clients (22,000)coupled with the stringent requirements placed on the server to supplythe content to each client has created problems that “on-demand” systemshave yet to economically overcome.

[0016] One prior art development in the LAN/WAN technology is called“multicasting.” Multicasting in LAN/WAN parlance means that only onecopy of a signal is used until the last possible moment. For example, ifa server in New York wants to deliver the same data to someone in KansasCity, Dallas, San Francisco, and Los Angeles, then only one signal needsto be sent to Kansas City. There it would be replicated and sentseparately to San Francisco, Los Angeles, and Dallas. Thus thetransmission costs and bandwidth used by the transmission would beminimized and the server in New York would only have to send one copy ofthe signal to Kansas City. This scenario is illustrated in FIG. 1A.

[0017] Multicasting helps to somewhat mitigate the transmission costsbut there are still a great number of cases where it provides littleoptimization. For example, if there is one person in each city in the USthat wants to view the same program generated by the server in New York,then the server must send the signal to all those cities, effectivelymultiplying the amount of bandwidth used on the network. As such, thetransmission is still expensive. Further, the multicast system modelbreaks down at high bandwidths and during periods of low data throughputwithin the Internet infrastructure, resulting in annoying degradation ofthe transmission content.

[0018] Another issue is distribution of information between autonomoussystems. This is called peering. FIG. 1B shows three autonomous simplesystems labeled AS0, AS1 and AS2. These autonomous systems are selfcontained networks consisting of host computers (clients and servers)interconnected by transmission facilities. Each autonomous system isconnected to other autonomous systems by peering links. These are shownin FIG. 1B by the transmission facilities labeled PL01, PL02 and PL12.

[0019] Peering allows a host in one autonomous system to communicatewith a host in a different autonomous system. This requires that therouters at the end of the peering links know how to route traffic fromone system to the other. Special routing protocols, such as boundarygateway protocol, enable the interconnection of autonomous systems.

[0020] Assume that host H1 in AS0 wants to communicate with host H2 inAS1 and H3 in AS2. To do this, H1 communicates with PL01 to reach H2 andPL02 to reach H3. If host H1 wants to multicast a message to multiplehosts in each of the autonomous systems, then boundary routers involvedmust understand the multicast protocols.

[0021] Backbone providers that form each of autonomous systems arereluctant to enable multicast over their peering links because of theunknown load placed on boundary routers and billing issues related tothis new traffic which originates outside of their autonomous systems.

[0022] The present inventors have recognized that a different approachmust be taken to provide a large amount of content to a large number oflisteners. In their prior art published European patent application, thepresent inventors proposed a system that abandons the “on-demand’ modeland point-to-point connection models. In their place, the presentinventors combined, among other things, a particular, unique “broadcast”model with localized multicast connections that selectively allow aclient to receive the high bandwidth content of the broadcast.

[0023] As the present inventor's prior published patent applicationexplained, the broadcast model assumes that the server delivers specificcontent at specific times on a specific channel as is currently done intoday's radio and television industry. “Near on demand” can be affectedby playing the same content at staggered times on different transmissionchannels, preferably, dedicated satellite broadcast channels. Localizedreceivers receive the broadcast channels and convey the content over anetwork using a multicast protocol that allows any client on the networkto selectively access the broadcast content from the single broadcast.This single broadcast provides, in effect, an overlay network thatbypasses congestion and other problems in the existing Internetinfrastructure.

[0024] As also explained in the prior published application: FIG. 1Cshows how host H1 multicast directly to H2 and H3 via satellite oranother dedicated link separate from the backbone of the Internet. Thistype of interconnection bypasses the peering links and the resultingcongestion and billing issues. This type of prior art interconnectionmaintains, however, a party-line sharing of bandwidth in the dedicatedlink. It also is, in essence, generally part of a two-way connectionadapted to provided TCP/IP information exchange in cooperation with,typically, a terrestrial back channel from the satellite receptionentity to the entity providing the content for transmission through thesatellite or other dedicated link.

[0025] The applicants' prior published European application wastherefore based on the applicant's discovery of, among other things, theadvantage of using a separate dedicated link and implements theresulting solution in a unique manner. Accordingly, the presentapplicants provided a data transmission system capable of sendingmultiple channels of broadcast or multicasting data or “content” toreceiving computers without being delayed or impaired by the bandwidthand constraints of two-way Internet connections.

[0026] The applicants' have discovered, however, that one problem withthe applicants system is that, although the near-on-demand delivery isvery advantageous, by itself, it does not allow for the level offlexibility an Internet user may desire in playing or accessing contenton demand and, for example, long after the near-on-demand delivery hasterminated for any given content.

[0027] Another problem that the applicants have discovered is that thebroadcast model itself is unduly limited in its ability to meet thedemands, and satisfy the needs of, providers of localized orregionalized advertising and similar types of localized content. Thesatellite broadcast model, for example, typically delivers the samecontent to all users nationally. This creates a significant problem fordistribution of localized content, such as locally tailored advertising,through such a non-localized broadcast system. The providers of suchlocally tailored advertising frequently do not purchase advertising insuch non-localized broadcasts, and the potential market demand foradvertising through such mediums is correspondingly limited.

[0028] Similarly, those who seek to provide locally-tailored advertisinghave had to seek other avenues (such as dealing individually withlocalized broadcasters in each localized market) in order to advertise.This effort is time consuming and expensive.

[0029] Also, even when pursuing locally-tailored advertising,advertisers are often forced by the available traditional media topurchase advertising in unnecessarily large regions or for delivery torecipients who are not as targeted as might be desired by theadvertiser. The applicants' embodiment disclosed in the applicants'prior art patent application did not solve this type of problem in andof itself.

SUMMARY OF THE INVENTION

[0030] The applicants have developed methods and apparatus formulticasting or broadcasting digital data to users accessing an Internetconnection. The methods and apparatus preferably include placing digitaldata that is to be multicast in IP protocol to generate IP digital data.The IP digital data preferably is transmitted from a transmission siteto a remote Internet point of presence through a dedicated transmissionchannel substantially separate from the Internet backbone. The dedicatedtransmission channel may be, for example, a satellite channel. At theremote Internet point of presence, local commercials preferably can beinserted into the IP digital data and/or the signal can be delayed forlater playback. The IP digital data is then preferably multicast fordelivery to a receiving Internet users apparatus connected to but distalfrom the remote Internet point of presence.

[0031] As will be readily recognized, the foregoing method and apparatuseliminate, or reduce the severity of, problems discussed above inconnection with existing multicast or broadcasting systems. Further,since the principal equipment used to implement the method is disposedat the point of the Internet Service Provider, the normal psychologicalreluctance of an Internet user to purchase extraneous multicastequipment is avoided. Other significant advantages of the applicants'disclosed apparatus and method will become apparent.

[0032] In one embodiment disclosed herein, the applicants have includeda method and apparatus for scheduling and recording IP multicastinformation in order to allow the user-recipient to record or store thebroadcasted or multicasted audio or video information for later playbackon demand.

BRIEF DESCRIPTION OF THE DRAWINGS

[0033]FIGS. 1A and 1B are drawings used to illustrate problems ininter-city communications over, for example, the Internet usingconventional systems.

[0034]FIG. 1C illustrates an alternative delivery system to the systemof FIG. 1B.

[0035]FIG. 1D illustrates a conventional network architecture.

[0036]FIG. 2 illustrates a hybrid broadcast I multicast networkconstructed in accordance with one embodiment of the present invention.

[0037]FIG. 3 illustrates one manner in which the Internet Protocoladdresses may be mapped at an Internet Service Provider.

[0038]FIG. 4 is a block diagram of one embodiment of a file serverstation, such as one suitable for use in the conventional system of FIG.1.

[0039]FIG. 5 illustrates one embodiment of a routing station constructedin accordance with one embodiment of the present invention and itsconnection within a network domain.

[0040]FIGS. 6 and 7 illustrate use of a routing station constructed inaccordance lip the invention and its connection at an Internet ServiceProvider.

[0041]FIG. 8a illustrates one embodiment of an uplink site suitable foruse in the network of FIG. 2.

[0042]FIG. 8b illustrates one embodiment of a downlink site suitable foruse in the network of FIG. 2.

[0043] FIGS. 9-11 illustrate various embodiments of downlink sitessuitable for use in the network of FIG. 2.

[0044]FIGS. 12 and 13 illustrate various manners in which variouscomponents of a downlink site may be modularized and interconnected.

[0045]FIG. 14 illustrates one embodiment of the multicast system at anISP with distributed POPs that are interconnected with one another.

[0046]FIGS. 15 and 16 illustrate one embodiment of an IPMS.

[0047]FIG. 17 illustrates a packet protocol that may be used by thecontroller unit to communicate through the monitor and control interfacesoftware.

[0048]FIG. 18 illustrates one embodiment of a transponder unit.

[0049]FIG. 19 is a schematic block diagram of selected components of oneembodiment of a transponder unit including a descrambler.

[0050]FIG. 20 illustrates one embodiment of a packet filter used in thetransponder unit of FIG. 18.

[0051] FIGS. 21-26 illustrate various configurations for networks usingan IPMS constructed in accordance with the present invention.

[0052] FIGS. 27-29 illustrate a further manner of deploying the presentsystem at an ISP.

[0053]FIG. 30 illustrates one example of a web page layout for use inselecting baud rate of a video transmission at a user of the presentsystem.

[0054]FIG. 31 illustrates a simple video distribution system.

[0055]FIG. 32 illustrates the insertion of local content servers in avideo distribution system.

[0056]FIG. 33 illustrates the hardware configuration needed for localinsertion.

[0057]FIG. 34 illustrates local content insertion in a multicast system.

[0058]FIG. 35 illustrates local content insertion in a multicast andInternet system.

[0059]FIG. 36 illustrates a delay play system.

[0060]FIG. 37 illustrates the equipment needed in a satellite uplink fora multicast system.

[0061]FIG. 38 illustrates the equipment needed at a satellite downlinkcapable for receiving a multicast transmission.

[0062]FIG. 39 illustrates equipment needed for satellite multicasttransmission.

[0063]FIG. 40 illustrates a simplified multicast transmission system.

[0064]FIG. 41 illustrates the timing for a single packet measurementsystem.

[0065]FIG. 42 illustrates the timing for a multi-packet measurementsystem.

[0066]FIG. 43 illustrates a local replay system.

[0067]FIG. 44 illustrates client software components for a local replaysystem.

[0068]FIG. 45 illustrates a satellite uplink system configuration.

[0069]FIG. 46 illustrates the equipment list for a satellite uplinksystem.

[0070]FIG. 47 illustrates the system for an ISP satellite downlink.

[0071]FIG. 48 illustrates the system for a NSP satellite downlink.

[0072]FIG. 49 illustrates the equipment list for a satellite downlink.

[0073]FIG. 50 illustrates a national video distribution architecture.

[0074]FIG. 51 illustrates method 1 of local co-branding nationalcontent.

[0075]FIG. 52 illustrates method 2 of local co-branding nationalcontent.

[0076]FIG. 53 illustrates local content insertion with localco-branding.

[0077]FIG. 54 illustrates local content, local ad insertion and localco-branding.

DETAILED DESCRIPTION OF THE INVENTION

[0078] The current networking architecture of today is generallyillustrated in FIG. 1D. As illustrated, the network, shown generally at50, comprises a group of host computers H1-H6 that are interconnected bytransmission links P1-P13 and routers R1-R6 to form a LAN/WAN. Anaggregated group of hosts is called a domain. Domains are grouped intoautonomous systems that are, in-turn, interconnected together to form anetwork. When these networks span a large geographic area, they arecalled a wide area network or WAN. An example of this networkarchitecture is the Internet and is illustrated in FIG. 1D.

[0079] At each interconnection node is a device called a router,designated here as R1-R6. The function of the router is to receive aninput packet of information, examine its source and destination address,and determine the optimal output port for the message. These receive,route determinations, and transmit functions are central to all routers.

[0080] If host H1 wants to send a message to host H3, there are avariety of paths that the signal could take. For example, the signalcould be transmitted along the transmission path formed by P1-P4-P8-P10.Other alternatives include the paths formed by P1-P2-P5-P7-P9-P10 orP1-P4-P6-P7-P9-P10. The function of the router is to determine the nextpath to take based on the source and destination address. The routermight use factors such as data link speed or cost per bit to determinethe best path for the message to follow.

[0081] As more host computers are brought on-line, more domains arecreated. Each time a domain is created, any router associated with thedomain must announce to its peers that it is present and ready to accepttraffic. Conversely, if a domain is deleted, the system must respond byremoving the paths and rerouting all messages around the removed domain.In any large network, there will be a constant addition and removal ofdomains. The success of the network architecture to respond to thesechanges is at the core of the networking problem. To this end, eachrouter communicates with its peers to announce to the network ornetworks it services. This implies that a bi-directional link shouldexist at each router. Terrestrial telephone circuits have traditionallysupplied these links on the Internet.

[0082]FIG. 2 illustrates a hybrid broadcast/multicast constructed inaccordance with one embodiment of the present invention. The system isillustrated in the context of a plurality of interconnected Internetdomains A, B, and C. As noted above, a domain is an aggregate of one ormore hosts. For example, domain A may be a corporate LAN while domain Bmay be a LAN at an educational institution or the like. In theillustrated embodiment, domain C is shown as an Internet ServiceProvider (ISP) that usually sells local access to the Internet throughits domain. As such, domain C includes at least one access router R7having one or more modems through which local but remotely located ISPcustomers (hosts) 60 connect to the domain through POTS, T1 lines, orother terrestrial links. From domain C, the ISP customers 60 areconnected to the Internet.

[0083] In the preferred embodiment, a file server station 100 is used tostore and transmit broadcast transmissions to a satellite 55. As will beset forth in further detail below, the file server station 100 includesone or more file servers that can provide, for example, multimediacontent in TCP/IP format. The multimedia data is then encapsulated inHDLC or similar frame format and modulated to RF for transmission overone or more uplink channels of the satellite 55. The satellite 55re-transmits the HDSL encapsulated frames on one or more downlinkchannels having different carrier frequencies than the uplink channels.The downlink transmissions are concurrently received by domains A, B,and C at local routing stations x1, x2, x3. At each routing station x1,x2, x3, the original TCP/IP data transmitted from the file serverstation 100 is extracted from the received HDLC frames. The extractedTCP/IP data is selectively supplied to hosts within the domain that havemade a request to receive the data.

[0084] This satellite 55 network in effect provides an overlay networkthat bypasses or at least somewhat avoids congestion and limitations inat least some of the existing Internet infrastructure, such as inFIG. 1. Moreover, this satellite 55 network provides dedicated,guaranteed bandwidth for the transmission of multimedia data through thesatellite 55.

[0085] In the preferred embodiment, the transmissions from the fileserver station 100 preferably include one or more multimediatransmissions formatted in accordance with the IP multicast protocol. IPMulticast is an extension to the standard IP network-level protocol. RFC1112, Host Extensions for IP Multicasting, authored by Steve Deering in1989, describes IP Multicasting as: “the transmission of an IP datagramto a ‘host group’, a set of zero or more hosts identified by a single IPdestination address. A multi cast datagram is delivered to all membersof its destination host group with the same ‘best-efforts’ reliabilityas regular uni cast IP datagrams. The membership of a host group isdynamic; that is, hosts may join and leave groups at any time. There isno restriction on the location or number of members in a host group. Ahost may be a member of more than one group at a time.” In addition, atthe application level, a single group address may have multiple datastreams on different port numbers, on different sockets, in one or moreapplications.

[0086] IP Multicast uses Class D Internet Protocol addresses, those with1110 as their high-order four bits, to specify groups of IPMS units 120.In Internet standard “dotted decimal” notation, host group addressesrange from 224.0.0.0 to 239.255.255.255. Two types of group addressesare supported: permanent and temporary. Examples of permanent addresses,as assigned by the Internet Assigned Numbers Authority (LANA), are224.0.0.1, the “all-hosts group” used to address all IP IPMS units 120on the directly connected network, and 224.0.0.2, which addresses allrouters on a LAN. The range of addresses between 224.0.0.0 and224.0.0.255 is reserved for routing protocols and other low-leveltopology discovery or maintenance protocols. Other addresses and rangeshave been reserved for applications such as 224.0.13.000 to 224.0.13.255for Net News (a text based service). These reserved IP Multicastaddresses are listed in RFC 1700, “Assigned Numbers.” Preferably,transmissions from the file server 100 containing related multimediacontent are transmitted using a permanent address. Even more preferably,the same multimedia content is provided by the file server system 100 atmultiple data rates using different permanent addresses.

[0087] For example, a multimedia file containing an automobilecommercial may be concurrently transmitted for reception at a 28.8 KBdata rate, a T1 data rate, an ADSL data rate, etc. The 28.8 KBtransmission is transmitted using a first group of one or more permanentaddresses. The T1 data rate transmission is transmitted using a secondgroup of one or more permanent addresses, wherein the first groupdiffers from the second group. In this manner, a client having a highspeed Internet connection may chose to receive the more desirable highdata rate transmissions while a client having a lower speed Internetconnection is not precluded from viewing the content due to theavailability of the lower speed data transmissions. Additionally, acorresponding web page may be concurrently transmitted along with themulticast data or along the backbone of the Internet.

[0088] If permanent multicast addresses are not available, the TCP/IPaddresses used for the broadcast transmissions may use a block ofaddresses that are normally designated as administratively scopedaddresses. Administratively scoped addresses are used for thetransmission of commands and/or data within the confines of a domain foradministrative processes and are not supplied outside of the scope ofthe domain. In other words, any broadcast transmissions received usingthese administratively scoped addresses desirably remains within thebounds of the domain in which it is received. All addresses of the form239.x.y.z are assumed to be administratively scoped. If administrativelyscoped addresses are used, provisions must be made to ensure that thedomain does not use an administratively scoped address that is withinthe designated broadcast block for other system functions. This may beaccomplished in one of at least two different manners. First, the domaincan be reprogrammed to move the administratively scoped address used forthe other system function to an administratively scoped address thatdoes not lie within the broadcast block. Second, the routing station mayperform an address translation for any administratively scoped addresseswithin the broadcast block that conflict with an administratively scopedaddress used for other purpose by the domain. This translation wouldplace the originally conflicting address outside the conflict range butstill maintain the address within the range of permissibleadministratively scoped addresses. As above, the same multimedia contentis transmitted concurrently using different transmission data rates.

[0089] With respect to the use of administratively scoped addresses,assume that the system will utilize a block of addresses that contain65,535 addresses (16 bits of address space). This block will utilize apredetermined, default address block. For the sake of this description,assume that the system default address space is defined as 239.117.0.0to 239.117.255.255. This address space is defined by fixing the uppertwo bytes of the address space (in this case 239.117) while merelyvarying the lower two bytes of data to allocate or change the address ofa channel of TCP/IP multimedia data. This addressing scheme, in and ofitself, will provide the system with 64K possible channels but it mayplace restrictions on the ISP environment since they would be requiredto have a dedicated block of 64K address space, one in which none of the64K addresses are being used by other applications. This may not alwaysbe feasible. In order avoid this kind of limitation, the system may onlyactually utilize the first 16K of the predefined address space. Thiswill allow 16K channels for the entire system, which corresponds to aminimum aggregate data rate of 470 MHz (assuming every channel isrunning the minimum data rate of 28.8 kbps).

[0090] Even with the limited number of addresses, there are still twopotential types of problems within the ISP environment. In the firsttype of problem, a limited number of the system broadcast addresses arealready in use at the ISP or other domain type. In the second type ofpotential problem, a large block of the system broadcast address spaceis being used at the ISP or other domain type. In either case, the IPMSmust be able to provide a solution for these two types of problems.These two cases are preferably addressed differently.

[0091] The most likely address conflict to be encountered in an ISP isthe first one noted above, designated here as the “limited address”conflict. This type of conflict occurs when a single address or severalisolated addresses within the broadcast address range are alreadyallocated within the ISP or other domain type. The fact that only 16Kaddresses out of the 64K address block are used will provide a means forrouting “around” these limited address conflicts.

[0092] As illustrated in FIG. 3, the 64K address space shown generallyat 80 will be divided into four 16K address blocks 85. The followingdiagram shows how the address blocks are defined. The system defaultaddresses are all located in block 0 which begins at address 0 of theadministratively scoped addresses.

[0093] The ISP or domain will setup a “routing table” within a routingstation of the domain that indicates all of the administratively scopedaddresses used within the ISP or domain. The routing station isprogrammed to re-route addresses with conflicts to the next availableaddress block. For example, if the ISP has address 239.117.1.11 alreadyassigned, the routing station routes this address to the next availableblock. The next available address block is found by adding 64 to thesecond byte of the IP address. For this service the next address wouldbe 239.117.65.11. If this address is free, this is where the routingstation re-routes the data associated with the conflicting address. Fouralternate addresses may be assigned for rerouting a single channelhaving a conflicting address.

[0094] The address re-routing scheme should be implemented on both therouting station end and in any client Plug-In software used to receivethe data. On the routing station side, once the ISP enters all addressconflicts, the routing station performs address translation on all ofthe addresses that conflicts occur. All packets have their addressesre-mapped to the new location. If a single address can not be re-routed(all four address blocks are used for a given channel) then the receiverperforms major address block re-routing as would occur in address blockconflict management described below. On the client software side, theclient opens sockets for all four address blocks (either sequentially orsimultaneously). The address that provides valid broadcast data isaccepted as the correct channel. The three other sockets are closed. Ifnone of the addresses provide valid data, the client tries the alternateaddress block as defined below.

[0095] Alternative strategies for reconciling addressing conflicts mayalso be employed. As an example, an agent might be implemented with theIPMS which could be queried by the client for the appropriate address touse at a particular location. Such a query would include a “logical”channel number associated with the desired broadcast. The agent wouldthen respond with the specific IP Address locally employed for thatbroadcast.

[0096] If a large number of addresses conflict with the default systemaddress space, an alternate block of addresses will be used. The systemdefines the exact alternate address space (or spaces), but as anexample, if 239.117.X.Y is the primary default broadcast block, anaddress space like 239.189.X.Y might be used as an alternate. In anyevent, the routing station will determine, based on the addressconflicts entered by the ISP, if the entire broadcast address block mustbe re-routed. If it does, the routing station will modify each broadcastchannel's address. As described above, if the client software can notfind a valid broadcast stream within the standard address block, thealternate address space will be tried.

[0097] Routing multicast traffic is different than the routing ofordinary traffic on a network. A multicast address identifies aparticular transmission session, rather than a specific physicaldestination. An individual host is able to join an ongoing multicastsession by issuing a command that is communicated to a subnet router.This may take place by issuing a “join” command from, for example, anISP customer to the ISP provider which, in turn, commands its subnetrouter to route the desired session content to the host to which therequesting ISP customer is connected. The host may then send the contentusing, for example, PPP protocol to the ISP customer.

[0098] Since the broadcast transmission is provided over a dedicatedtransmission medium (the satellite in the illustrated embodiment),problems normally associated with unknown traffic volumes over a limitedbandwidth transmission medium are eliminated. Additionally, the numberof point-to-point connections necessary to reach a large audience isreduced since the system uses localized connections within or to thedomain to allow clients to join and receive the broadcast. In theillustrated embodiment, a virtually unlimited number of domains mayreceive the broadcast and supply the broadcast to their respectiveclients, additional domains being added with only the cost of therouting station at the domain involved. In most instances, ISPs or thelike need only add a routing station, such as at x1 et seq., and may usetheir existing infrastructure for receiving broadcasts from the routingstation for transmission to joined clients. This is due to the fact thatmost ISPs and the like are already multicast enabled using the IPmulticast protocol.

[0099]FIG. 4 illustrates a block diagram of one embodiment of a fileserver station, such as the one illustrated at 100 of FIG. 1. The fileserver station, shown generally at 100, comprises a local area network102 with a collection of server PCs 105 connected to a router 110 overthe local area network 102. The server PCs 105 include server softwarethat either reads pre-compressed files from the local disk drive and/orperforms real time compression of analog real time data. Each server 105provides this data as output over the local area network.

[0100] The LAN 102 performs the function of multiplexing all thestreaming data from the server PCs 105. The LAN 102 should havesufficient bandwidth to handle all the data from the server PCs 105. Inpresent practice, 100 mbs LANs are common and, thus, it is quitefeasible to use 100 mbs LANs to aggregate the data output to a 30 mbstransponder. A common type of LAN is or 100Base T, referring to 100 mbsover twisted pair wire.

[0101] The functionality required at 110 is to gather the packets ofdata from the LAN 102, wrap them in a transport protocol such as HDLC,and convert the HDLC packets to the proper voltage levels (such asR5422). The functionality can be provided by the composite signalprovided from the router 110 usually comprises clock and data signals.The composite signals are output from the router 110 for synchronousmodulation by a satellite uplink modulator 115 which synchronouslymodulates the data to the proper RF carrier frequencies and transmitsthe resulting signal through an antenna 122 to the satellite 55.

[0102] One or more server PCs 105 of the LAN 102 store the multimediacontent that is to be broadcast to the domains. Alternatively, the oneor more PCs 105 may receive pre-recorded or live analog video or audiosource signals and provide the necessary analog-to-digital conversion,compression, and TCP/IP packet forming for output onto the LAN wanted.These packets are transported over the LAN 102 in an asynchronousmanner. The router 110 then receives these asynchronous packets andencapsulates them with the transport protocol and transmits them in asynchronous manner to the satellite 55. The constant conversion from oneform to another is provided to fit the transmission technologies of thetransmission equipment. LANs are becoming ubiquitous and low cost sinceit leverages the high manufacturing volumes of the consumer/corporate PCmarket. Satellite transmission is extremely cost effective forbroadcasting signals to multiple destinations and is inherentlysynchronous (data is transmitted at precise intervals). Accordingly, theforegoing system is currently the most straight forward and lowest costmethod to architect a system a connecting computer LANs to a satellitetransmission system.

[0103] A typical satellite 55 has two antennas, one for receiving thesignal from the uplink and the second antenna for transmitting thesignal to the downlink. An amplifier is disposed between the twoantennas. This amplifier is responsible for boosting the level of thesignal received from the file server station 100 (uplink). The receivedsignal is very weak because of the distance between the uplink and thesatellite (typically about 23,000 miles). The received signal isamplified and sent to the second antenna. The signal from the secondantenna travels back to downlinks which are again about 23,000 milesaway. In the illustrated embodiment of the system, the downlinks are therouting stations.

[0104] The signal is transmitted by the uplink at one frequency andshifted to a different frequency in the satellite before amplification.Thus, the signal received by the satellite is different from thefrequency of the signal transmitted. The transmitted information contentis identical to the received information.

[0105] A typical satellite has approximately 20 to 30 RF amplifiers,each tuned to a different frequency. Each of these receive/transmitfrequency subsystems is called a transponder. The bandwidth of each ofthe transponders is typically about 30 MHz but can vary satellite tosatellite.

[0106] At the file server station 100, the composite signal from therouter 110 is preferably QPSK modulated by the satellite uplinkmodulator. During the modulation process, extra bits are usually addedto the original signal. These extra bits are used by a receiver at thedownlink to correct any errors which might occur during the 46,000 miletransmission. The extra protection bits that are a added to the datastream are called Forward Error Correction bits (FEC).

[0107] The resulting modulation and error correction process typicallyallows about 1 megabit/second of data to occupy about 1 megahertz (MHz)of bandwidth on the transponder. Thus, on a 30 MHz bandwidthtransponder, one can transmit about 30 mbs of data. The aggregate datarate of the signals generated by all server PCs 105, including theoverhead of the underlying transmission protocols (IP and HDLC), must beless that the bandwidth of the satellite transponder.

[0108]FIG. 5 illustrates one embodiment of a routing station and itsconnection within a domain. Here, the routing station is called an IPMulticast Switch (IPMS), labeled as 120 in FIG. 5. The IPMS 120 iscomprised of a demodulator 125 that receives the radio frequency signalsfrom the satellite 55 over receive antenna 130 and converts them intothe original TCP/IP digital data stream. These digital signals are theninput to a device called a IP Multicast Filter (IPMF) 140 that in-turnselectively provides the signals as output onto a LAN, shown generallyat 145, having sufficient capacity to handle all the received signals.The IPMS 120 is multicast enabled, meaning that data is only output fromthe IPMF 140 onto the LAN 145 if a client 160 requests a connection toreceive a broadcast channel. As noted above, this multicast protocol maybe one such as defined in RFC 1112.

[0109] As illustrated, the LAN 145 can be connected to the Internet 165through a router 170. If the broadcast data output on the LAN 145 usesadministratively scoped addresses, the router 170 can prevent forwardingof the data to the Internet 165. This is a desirable feature associatedwith the use of administratively scoped addresses, as the broadcast canbe localized and blocked from congesting the Internet 165. If otheraddresses are used, such as permanent IP multicast addresses, the router170 is programmed to prevent data having an IP multicast address frombeing broadcast on the Internet 165.

[0110] The software of the IPMS 120 is capable of operating in an IPmulticast network. In the embodiment described here, the controlstructure of the multicast software in the IPMS 120 has four mainthreads: initialization, multicast packet handling, LAN packet handling,and multicast client monitoring. In the initialization thread, a tableused to determine whether a client has joined a broadcast has itscontent set to an empty state, Initialization is performed before any ofthe other threads are executed.

[0111] The multicast packet handling thread is responsible for readingdata from the satellite demodulator and deciding what is to be done withit. To this end, the thread reads each multicast packet received fromthe satellite demodulator 125. If the multicast group address specifiedin the received packet is not in a group table designating the groupsreceived from the satellite 55 by the demodulator 125, the group addressis added to the group table and set to “not joined.” If the multicastgroup address specified in the packet is specified in the join table ashaving been joined by a client, the packet is output through the IPMS120 to the LAN 145 for receipt by a requesting client 160. If none ofthe foregoing tests are applicable, the packet is simply ignored.

[0112] The LAN packet handling thread is used to determine whether ajoin command has been received from a client 160 over the LAN 145. Tothis end, the IPMS 120 reads an IP packet from the LAN 145. If thepacket is a request from a client 160 to join the multicast session andit is in a group table (a table identifying groups which the IPMS 120 isauthorized to receive), the group address is added to the list of joinedaddresses in the join table. In all other circumstances, the packet maybe ignored.

[0113] The multicast client monitoring thread is responsible forperforming periodic checking to ensure that a multicast client who hasjoined a broadcast is still present on the LAN 145. In accordance withRFC 1112, every predetermined number of seconds, or portions thereof,for each group address in the group table which has joined the multicastsession a query is sent to that address and the IPMS 120 waits for aresponse. If there is no response, the IPMS 120 assumes that all joinedclients have terminated and removes the group address from the joinedlist.

[0114] It will be recognized that other further software threads andvariations on the foregoing threads may be used. However, in thesimplest form of the illustrated embodiment, the four threads describedabove are all that is practically needed for effective IPMS operationwhere the IPMS 120 is disposed at an outer edge of a domain network.This simplification provides a reduction in complexity in the IPMS 120.

[0115] If there are one or more routers between the IPMS 120 and themulticast client 160, then the IPMS 120 is programmed to understand thevarious multicast protocols such as DVMRP, MOSPF and RIM. Theseprotocols are well known and can easily be implemented in the IPMS 120.

[0116] In either configuration, the IPMS 120 appears to the domainnetwork as the source of the data, and the satellite link effectivelyplaces an identical server at each downlink location in the separatedomains described in connection with FIG. 2.

[0117] It is generally preferable to have the IPMS 120 as close aspossible to the last point in the network before transmission to aclient. This close proximity to the client minimizes the traffic burdenon other system routers and the overall local LAN. The Internet ServiceProvider's (ISP) local Point of Presence (POP) is generally the optimumlocation for placement of the IPMS 120 at an ISP. Such a configurationis illustrated in FIG. 6.

[0118] As shown in FIG. 6, the ISP, shown generally at 200, is connectedvia an access router 205 to the Internet 165. If a distribution router210 is located some distance from the Internet access router 205, theninter-POP communications are required through one or more intermediaterouters 207. These inter-POP communications may take place via framerelay or SMDS (Switched Multimegabit Data Service) since these arerelatively inexpensive communication methods. In the POP 215, the IPMS120 is connected to the backbone LAN 220. This LAN 220 is connected tothe distribution router 210 and provides the connectivity to thecustomer base. Typically, the distribution router 210 is connected to aLocal Exchange Carrier (LEC) 230 through telephone company interconnectssuch as T1, T3, and ATM lines and, thereafter, to remotely located homeusers/clients 235.

[0119] The architecture of FIG. 6 allows customers 235 to place local(free) calls into the distribution router 210 that, in turn, allows thecustomers 235 to access the Internet 165 through some remote accesspoint. If the POP 215 and the Internet access at access router 205 areco-located, then the ISP LAN 240 and the POP Backbone LAN 220 are one inthe same and there are no intermediate routers or intervening inter-POPcommunications.

[0120]FIG. 7 illustrates a system in which the IPMS 120 is not disposedat the POP 215 location. This arrangement is functional, but requires alarge amount of bandwidth over the inter-POP communication lines 245.The configuration shown in FIG. 6 minimizes the bandwidth requirementsof the router interconnections relative to the configuration shown inFIG. 7 since only the POP Backbone IAN should include both thetraditional Internet traffic as well as the Multicast traffic.

[0121] As can be seen from examination of FIGS. 6 and 7, the addition ofmulticast equipment to the ISP's POP 215 is minimal It is also possibleand desirable to add a traffic server PC 255 onto the LAN of the ISP 200having the IPMF 120 (also known as a multicast switch). This trafficserver 255 can be used for a variety of purposes, but in the embodimentshown here, it is used to store information received from the satellite55 and the Internet 165 for later playback. It also can be used tomonitor the number and identification of a connected user as well asperforming other functions. For example, when a user selects avideo/audio multicast channel to view/hear, it sends a specific IGMPmessage over the LAN that is directed to the IPMS 120. This message canalso be monitored by all systems connected to the LAN. Specifically, thetraffic server 255 may monitor the communication between the router 210and any connected clients and may also monitor the number of connectionsto the multicast channels. The connection information gathered by thetraffic server 255 is preferably relayed to a central server or the likeover the Internet 165 at periodic intervals for consolidation at acentral facility.

[0122] One advantage of the foregoing system architecture is that itprovides a scaleable architecture that may be scaled to deliver a smallnumber of megabits as well as further scaled to deliver nearly a gigabitof content to a large number of host computers. This architecture isonly constrained by satellite transponder capacity, which is typicallyabout 30 mbs per transponder.

[0123]FIGS. 8a and 8 b illustrate the uplink and downlink systemssuitable for handling at least 60 mbs. File server stations, such as theone shown at FIG. 4, typically only have a capacity of 30 mbs. As such,the uplink here uses two file server stations 100 a and 100 b. On theuplink side, a second cluster of server PCs 105 is connected to a secondrouter 110 b, which is connected to the uplink equipment and transmitsthe signal over the same satellite 55 using a different transponderfrequency. Alternatively, the transmission of signals from the secondrouter 110 b may be directed to a different satellite than the one usedby the first file server station 100 a. If the two signals are uplinkedonto the same satellite, then it is possible to share a common antenna.

[0124] At the downlink side of FIG. 8b, there are two IPMS units 120 aand 120 b, which are each identical to that described above. If the twosignals are uplinked on the same satellite, it is possible to share anantenna 130 on the downlink as shown in FIG. 8b. If not, then twoseparate antennas are required, one pointing to each of the differentsatellites. In the scenario shown in 8 b, the two IPMSs 120 a and 120 bare connected to a 100baseT LAN 280. The maximum bit-rate delivered tothe LAN 280 is the sum of the individual bit rates of the IPMSs 120 aand 120 b, or about 60 mbs. This is a convenient number since themaximum real capacity of a 100BaseT LAN is about 60 mbs.

[0125] Additional file server stations and IPMSs may be added to theforegoing system to increase the number of available multimediamulticast channels available to the ISP clients. For example, a 90 mbssystem may be constructed by adding a further file server station at theuplink side of the system and adding a further IPMS at the ISP POP. Thisthird IPMS, however, presents a problem for a 100BaseT LAN since thetotal possible throughput can now exceed the allowable LAN bandwidth.The traffic server 255 can be used to assist in eliminating thisproblem.

[0126] At the heart of the multicasting protocol is the fact thatgenerally no unnecessary traffic is forwarded unless someone hasrequested it. This means that even if there is 90 mbs of total datareceived from the satellite, there would be no data output to the100BaseT LAN if there were no clients requesting a connection to it.

[0127] On the other hand, it is possible that there could be clientsrequesting placement of the entire 90 mbs on the LAN. Such traffic wouldsaturate the LAN 280. To mitigate the problem, there are at least twopotential solutions.

[0128] The first solution is to modify the client software so that itfirst contacts the traffic server 255 to determine how much bandwidth isalready delivered to the LAN 280. If the LAN is already delivering themaximum possible data to other clients, then the client currently tryingto connect is given a message stating that the system is too busy.

[0129] A second solution is to have an IPMS first contact the trafficserver 255 to check the load on the LAN 280 before providing a channelof multicast data on the LAN 280. To this end, the IPMS 120 contacts thetraffic server 255 after a request has been made for a channel ofmulticast data but before the data is supplied on the LAN 280. If thetraffic server 255 deems that the load is too high, it instructs theIPMS 120 to ignore the join request and refrain from transmitting therequested group on the LAN 280. As a result, the requesting client wouldnot receive the requested video/audio stream. The client software mayindicate the failure to receive the requested data upon termination of apredetermined time period and indicate this fact to the user.Nevertheless, the applicants believe that there is a high probabilitythat 90 to 120 mbs of data could be uplinked with no downlink overloadon the LAN, since it is highly unlikely that all data rates of allchannels would be simultaneously used.

[0130] The traffic server software could be imbedded into one of the IPMulticast Switches 120 and thus eliminate separate traffic serverhardware 255. If the system data is scaled even higher, then thearchitecture shown in FIG. 9 is used at the downlink side of the system.The transmission data rate at the uplink side is obtained by merelyadding further file server stations 100. The system shown a in FIG. 9adds a new piece of hardware called gigabit switch 290. On the rightside of the switch 290 is a connection to the LAN 300. The LAN 300 inthis embodiment is capable of handling the total aggregate bandwidthoutput by all IPMSs 120. For the case where each IPMS 120 is receiving30 mbs and there are 10 IPMSs, then the aggregate bandwidth is 300 mbs.This implies that the LAN 300 is capable of handling such traffic.

[0131] As further illustrated in FIG. 9, a controller 310 may be used tocommunicate with the LAN 300 and, further, with the demodulators 125 andIPMFs 140 over a communication bus 315. Such an architecture allows thecontroller 310 to program the specific operational parameters used bythe demodulators and IPMFs. Additionally, the demodulators 125 and IPMFs140 may communicate information such as errors, status, etc., to thecontroller 310 for subsequent use by the controller 310 and/or operatorof the routing station. Still further, the traffic server 255 may beused to facilitate inter-module communications between the IPMFs 140.

[0132] The connections between the IPMF 140 and the switch 290 may bethe 100BaseT connections shown in the previous figures. This impliesthat the switch 290 requires n-100BaseT input ports to accommodate then-IPMS inputs. The system proposed in FIG. 9 assumes the use of gigabitaccess and distribution routers, gigabit LANs and gigabit switches. Suchnetwork components are in the very early stages of deployment.

[0133] A second architecture that can be used to scale to a large numberof a users is shown in FIG. 10 and is similar to the architecture shownin FIG. 9 in that they both include the satellite demodulators 125 andthe IP Multicast Filters 140. The system of FIG. 10, however, replacesthe traffic server 255 with an IP filter 325 and the gigabit switch 290with a standard 100BaseT hub 340. Another significant difference betweenthe two architectures is that the Internet access router 205 of FIG. 10is directly connected to the backbone of the gigabit LAN while theconnection for the Internet access by the clients 335 is through the IPfilter 325 within the LAN interface module. The IP filter 325 may beimplemented by a PC or the like, or by a microcontroller, The IP filter325 performs the functions of the traffic server 255 as well as simpleIP packet filtering. It passes each packet received from the Internetwithout examination or modification. This includes multicast as well asunicast traffic. Packets received from the hub 340 are examined on a perpacket basis. Multicast packets with a group address used by thesatellite delivered multicast system (shown here as the SatelliteInterface Unit (SIU)) are blocked from traversing onto the Internet.This prevents the Internet Access LAN from overload and serves thefunction of administratively scoping the multicast traffic to onesegment. This architecture also has an added advantage in that therouters used in the domain do not have to be multicast enabled.

[0134] The architecture shown in FIG. 10 can be viewed as dividing anISP into smaller ISP's within the larger ISP. Each of these mini-ISPshas its own IAN Interface Unit (LIU) 405. This architecture places aperformance requirement on the IP filter in that it must be capable ofprocessing all packets flowing through it via the 100 BaseT LANS towhich it is connected.

[0135]FIG. 11 illustrates a further system architecture that replacesthe IP filter 325 of FIG. 10 with a traffic server 255 and uses a{fraction (10/100)} BaseT switch 410 in place of the IP filter 325. Thisarchitecture requires the {fraction (10/100)} BaseT switch 410 toperform the IP multicast filtering that was done in the IP filter 325.

[0136] The interface point 417 of FIG. 11, between the IPMS and aparticular ISP LAN segment, may also be facilitated in cases where thatLAN segment is remotely located. Standard digital telecommunicationsservices may be employed to serve as electrical “extension cords” tobring the output of the IPMS onto the remotely located segment. This isdone through commonly available “CSU/DSUs” that can transform the LANoutput of the IPMS into a digital signal compatible with the NetworkInterface requirements of common communications carriers, and at theremote location, a subsequent translation back into the required 100BTLAN signal.

[0137]FIG. 12 shows one manner of implementing the architectures for thesatellite downlink. The IP Multicast Switch 120 can be functionally andphysically divided into a satellite interface unit 425 and a LANinterface unit 430. Multiple LAN interface units 430 may be connected toa single satellite interface unit 425. This allows the satellitereception equipment to be located at a first location and its outputdistributed to various remotely located LAN interface units. As shown inFIG. 3, the basic system architecture of FIG. 12 also allows for thedistribution of content via an alternate transmission facility such asterrestrial fiber 110. Alternatively, these two modules can reside inthe same chassis and use the chassis backplane for intermodulecommunication.

[0138]FIG. 14 illustrates an embodiment of the system at an ISP withdistributed POPs that are interconnected with one another. Thisembodiment of the system isolates the multicast traffic from the unicasttraffic. Inter-POP multicast traffic is carried on a separatetransmission facility.

[0139] One embodiment of an IPMS discussed earlier is illustrated inFIGS. 15 and 16. Generally stated, the embodiment of the IPMS unit 120shown here and subsequently described is comprised of a controller unit440 and one or more transponder units 445. The controller unit 440handles the monitoring, control, and configuration of the IPMS unit 120.The transponder units 445 performs demodulation and de-packetization ofthe RF signal data received from the satellite 55 and provides thedemodulated data to the hub 340 of a 100BT LAN 220 when directed to doso by the controller unit 440. In some implementations of the system,there may be a need for a splitter unit 450 that divides the RF signalfor supply to several transponder units 445.

[0140] As noted above, the controller unit 440 handles all monitor,control, and configuration of the IPMS unit 120. It maintains logs ofall of the events in the system and processes all incoming TCP/IPprotocol messages to the IPMS unit 120. These messages include the IGMPjoin requests from remote clients, individually addressed commands tothe controller unit 440, and packets destined to individual transponderunits 445. The controller unit 440 is responsible for logging all of thetrace type events in a non-volatile memory device, such as a hard diskdrive 455.

[0141] As illustrated, the controller unit 440 is comprised of amicroprocessor unit 460, two network interface cards (NIC) 465 and 467,a modem 470 for connection to a remote port, a video controller 475 forconnecting a video monitor, a keyboard interface 480 for connection to akeyboard, a DRAM 485 for storage, an RS-232 port 487 for externalcommunications, and the hard drive 455.

[0142] The microprocessor unit 460 may be an Intel Advanced ML (MARL)Pentium motherboard. This board has two serial ports, a parallel port, abus mastering IDE controller, a keyboard interface, a mouse interface,support for up to 128 MB of DRAM, and a socket for a Pentiummicroprocesser. The board supports 3 ISA extension boards and 4 PCIextension boards. The MARL motherboard is designed to fit into thestandard ATX form factor.

[0143] The RS-232 port 487 supports commands from a remote port that canbe used for both monitor and control functions. This interface supportsstandard RS-232 electrical levels and can be connected to a standardpersonal computer with a straight through DB-9 cable. The software usedto implement the interface supports a simple ASCII command set as wellas a packet protocol that can be used to send commands that containbinary data.

[0144] Monitor and control interface software 490 executed by themicroprocessor unit 460 supports multiple communications settings forthe RS-232 port 487 by allowing the user to change the baud rate, thenumber of data bits, the number of stop bits, and the type of parity.These settings are saved in non-volatile memory so that they arepreserved after power has been removed from the receiver.

[0145] The monitor and control interface software 490 preferablysupports both a simple ASCII protocol and a more complex packetstructure. The ASCII protocol is a simple string protocol with commandsterminated with either a carriage return character, a line feedcharacter, or both. The packet protocol is more complex and includes adata header and a terminating cyclic redundancy check (CRC) to verifythe validity of the entire data packet.

[0146] The ASCII protocol is preferably compatible with a simpleterminal program such as Procomm or HyperTerminal. When an externalterminal is connected to the RS-232 port 47, the controller unit 440initially responds with a sign-on message and then displays its “ready”prompt indicating that the is ready to accept commands through themonitor and control interface software 490. Commands are terminated bytyping the ENTER key which generates a carriage return, a line feed, orboth. The controller unit 440 interprets the carriage return, as thetermination of the command and begins parsing the command.

[0147] Most commands support both a query and a configuration form.Configuration commands adhere to the following format:

cmd param1<,param>CR

[0148] where cmd is the command mnemonic, param1 is the first parametersetting, the <,param2>indicates an optional number of parametersseparated by commas, and CR is a carriage return.

[0149] Queries of commands can be entered in one of two forms asfollows:

[0150] cmd?CR or optionally

[0151] cmdCR

[0152] The controller unit 440 responds to the query with the commandmnemonic followed by the command's current setting(s).

[0153] The controller unit 440 may also communicate through the monitorand control interface software 490 using a predetermined packetprotocol. One such protocol is illustrated in FIG. 17. The illustratedprotocol is an asynchronous character based master-slave protocol thatallows a master controller to encapsulate and transmit binary and ASCIIdata to a slave subsystem. Packets are delimited by a sequence ofcharacters, known as ‘flags,’ which indicate the beginning and end of apacket. Character stuffing is used to ensure that the flag does notappear in the body of the packet. A 32-bit address field allows thisprotocol to be used in point-to-point or in point-to-multipointapplications. A 16 bit CRC is included in order to guarantee thevalidity of each received packet.

[0154] The opening flag 500 includes a 7E_(H) 01_(H) flag patternindicating the start of packet or end of the packet at 510. Atransaction ID 505 follows the opening flag 500 and is, for example, an8-bit value that allows the master external computer to correlate thecontroller unit 440 responses. The master computer sends an arbitrarytransaction ID to the controller unit 440, and the controller unit 440preferably responds with the 1's complement of the value received fromthe master. Following the transaction ID 505 is a value that allows themaster to identify the addressing mode of the packet. This portion ofthe packet is called the mode byte and is shown at 515. These addressingmodes include broadcast, physical, and logical modes. An address field520 and data field 525 follow the mode byte 515. The address field valueis used in conjunction with the mode field to determine if the slaveshould process the packet. The data field 525 contains informationspecific to the application. This field can be any size and is onlylimited by the application. Finally, a CRC-16 field 530 follows the datafield 525. The CRC-16 field 530 allows each packet to be validated. Eachbyte from the mode byte 515 to the last data byte is included in the CRCcalculation.

[0155] The monitor and control interface software 490 supports the samecommand set as both a remote port and a TCP/IP in-band signalingchannel. This allows the IPMS 120 to be controlled identically using anyof the possible control channels (although the physical connection andphysical protocol vary by connection) which provides redundant means ofmonitor and control. These commands are described in further detailbelow.

[0156] The controller unit 440 includes the hard drive 455 for itslong-term storage. This drive is preferably at least 2.1 GB in size anduses a standard IDE interface. The drive 455 is preferably bootable andstores the operating system, the application(s) running the IPMS 120,and all long-term (non-volatile) data such as history/trace data.

[0157] The network interface card 465 is used to communicate with all ofthe transponder units 445 in the IPMS 120. The network interface card465 is comprised of a 10 based-T LAN interface running standard TCP/IP.Individual commands are issued using the same protocol as set forthabove in connection with the monitor and control interface software 490as well as any remote port connected through modem 470. This protocol isencapsulated into TCP/IP and sent via an internal LAN 532 overtransmission line 535.

[0158] The network interface card 465 supports both broadcast andindividual card addressing. This interface also supports two-waycommunication that can be initiated by any unit on the internal LAN 532.Individual transponder units 445 may communicate with each other overthe internal LAN 532, although this interface is not truly intended tobe used in this fashion in the embodiment shown here. The 10 Based-Tinterface card 465 may be implement using any off-the-shelf networkinterface card.

[0159] The modem 470 of the controller unit 440 may also supportcommands that can be used for both monitor and control functions Themodem 470 supports standard phone modem electrical levels and can beconnected to a standard phone jack with a straight through RJ-11 cable.Both the ASCII and packet protocols noted above are supported by themodem 470. The modem 470 thus provides another communications route tothe IPMS 120 in case a standard TCP/IP link over the Internet to theIPMS 120 fails.

[0160] The modem interface 470 is implemented, for example, by anoff-the-shelf modem and auto-negotiates all communications settings witha Network Operations Center or NOC 472 at a location that is remote ofthe ISP. The Network Operations Center 472 preferably uses an identicalmodem.

[0161] The IPMS 120 includes several miscellaneous input and output (IO)functions that are not illustrated in FIGS. 15 and 16. These functionsmay be handled on either a plug in ISA board or a front panel board. TheIO may include status LEDs, a status dry contact closure, and a panicbutton. The status LEDs may be set through an I/O card. LED indicatorsmay include Power Present, Power OK, Fault, Test, Carrier OK, and LANActivity. The Power Present LED may indicate that the IPMS 120 isplugged into its main AC source. The Valid Power LED may indicate if thepower within the IPMS 120 is within valid tolerance levels. The FaultLED may indicate if a major fault is occurring in the IPMS 120. The TestLED may indicate that the IPMS 120 is in a test mode, either its powerup test or an on-line test mode. The Carrier LED may indicate that alltransponder units 445 that should be acquired (have been programmed tolock onto a carrier) are, in fact, locked. If any single transponderunit 445 is not locked, this LED will be off. The LAN activity LED mayindicate that the IPMS 120 has activity on its 100 based-T LAN.

[0162] A Form C dry contact closure may be provided to indicate thestatus of the IPMS 120. If the IPMS 120 goes into a fault condition, theIPMS 120 will provide an output signal along one or more lines at 540 todrive closure to a closed state. This provides a means of monitoring theoverall operational integrity of the IPMS 120 with an external devicetriggered by the contact closure. Devices that could be used includeautomatic pagers or alarm bells.

[0163] The IPMS 120 may also have a panic button that is used to turnoff outgoing multicast video. This will provide the ISP with a quick andefficient way of stopping the IPMS 120 data flow onto the ISP LAN 240 incases of extreme LAN congestion or a when a malfunctioning IPMS 120inadvertently congests the LAN 240. This button preferably will not takethe controller unit 440 link off of the network. This ensures that thecontroller unit 440 will still be susceptible to monitoring and controlthrough the TCP/IP port connected to the ISP's LAN 240.

[0164] Once the panic button has been pressed, the IPMS 120 issues a“LAN shutdown” to every transponder unit 445 through the networkinterface card 465. The individual transponder units 445 are responsiblefor shutting their LAN output off.

Controller Unit Software Functionality

[0165] The following sections provide a brief overview of one embodimentof the software functionality used to operate the controller unit 440.This software is preferably developed in accordance with anobject-oriented, C++, methodology.

[0166] The controller unit 440 preferably runs under a Microsoft WindowsNT Workstation operating system. This operating system supports all ofthe networking protocols needed as well as supporting the hardware foundin the controller unit 440.

[0167] 1. Networking Protocols

[0168] The networking protocols discussed above are supported by theoperating system. The operating system runs an HTTP server that allowscontrol of the controller unit 440 through a web browser type ofapplication.

[0169] 2. Watchdog Process

[0170] A hardware watchdog timer counter that must be periodically resetis used in the controller unit 440. If this counter runs out, itgenerates an interrupt that reset as the controller unit 440. Inaddition to this system level watchdog timer, individual applicationsmay maintain their own versions of watchdog monitoring to ensure thatthey do not “hang.” In cases where an individual task can restartwithout affecting the overall system, the task will be restarted. Incases where the system becomes unstable, the entire controller unit 440is preferably restarted in an orderly manner. In either case, an errorshould be generated and logged in the trace buffer.

[0171] 3. Software Download

[0172] The controller unit 440 handles software downloads for itself andfor all of the transponder units 445: Software downloads are preferablyperformed using FTP file downloads over the local ISP LAN the 240through NIC 467, from a remote station over the modem interface 470, orthrough the RS-232 port 487. Before a file is downloaded, FTP serversoftware in the controller unit 440 verifies that the download is, infact, a new file. The files are preferably downloaded into a fixeddirectory structure.

[0173] 4. Network Configuration Tables

[0174] The NOC 472 maintains a series of tables used to configure anetwork of systems such as the one shown in FIG. 15, each system beinglinked to the NOC 472. These tables may be downloaded using FTP or apredetermined table download command and are used by the controller unit440 to configure all of the transponder units 445 and to handle any datarate adaptation required by the system. The tables include a ChannelDefinition Table (CDT), a Carrier Table (CT), and a Channel ClusterTable (CC).

[0175] The Channel Definition Table (CDT) is used to define the locationand bandwidth of every channel containing, for example, multimediacontent, in the overall system. Each channel of the disclosed embodimenthas a unique ID that ranges from 0 to 16K. This ID is the same value asthe channel's default low order administratively scoped address bits.For example, channel 128 will have a default address of X.Y.0.128, whereX and Y are the administratively scoped high order address bytes(239.117 for example). The CDT also provides an indication of thecarrier frequency on which a channel can be found. The carriers areassigned a unique ID number that can be converted to a frequency anddata rate using the Carrier Table set forth below. The CDT also includesthe Channel Cluster ID of the cluster in which the channel appears, ifany. The Channel Cluster ID is defined in the Channel Cluster Tablesection below. Each CDT record preferably uses the following recordformat: Channel ID (8-bits) Transponder Number (16-bits) Data Rate (inKilobytes) (16-bits) Cluster ID (16-bits)

[0176] The CDT only contains records for defined channels in the overallsystem. If a channel is not defined, the IPMS 120 will assume that thechannel has zero bandwidth. The overall table will be represented in thefollowing form: Table ID (8-bit) Number of Channels (16-bit) ChannelRecords (40-bits per record * number of channels) CRC (16 bit)

[0177] The Carrier Table (CT) provides a means for identifying all ofthe carriers being used in the overall system. The records in the CTindicate the satellite transponder ID, the frequency of the carrier, itsdata rate, and the type of coding that the carrier is using (includingscrambling). The controller unit 440 provides these parameters to thetransponder units 445 to acquire the desired carrier. The CT recordsalso contain information about the satellite that the carrier istransmitted from and the polarity of the receive signal. The controllerunit 440 uses this information to notify an installer, through, forexample, a video terminal attached to the video controller 475, thatmultiple dishes are required. Further, the satellite ID is used todetermine the azimuth and elevation settings for an antenna that is toreceive the carrier transmission from the identified satellite. Eachrecord within the CT preferably has the following format: Carrier Number(16-bits) Frequency (in kHz) (32-bits) Data Rate (in Hz) (32-bits)Coding type (8-bits) Polarity (8-bits) Satellite ID (8-bits)

[0178] The overall table format for the CT is as follows: Table ID(8-bit) Number of Carriers (16-bit) Carrier Records (104-bits perrecord * number of carriers) CRC (16-bit)

[0179] The Channel Cluster Table (CCT) is used to describe a “cluster”of channels. A cluster of services is defined as a set of multiplechannels with the same content but using different data rates. Thisaspect of the present embodiment of the system is set forth above. TheCCT is used to allow a client to receive a channel at a different datarate from the one requested. For example, if a client requests a serviceat 1 Mb but the LAN 240 is congested or the controller unit 440 is closeto its maximum allowable bandwidth on the LAN, the controller unit 440can inform the client software (usually a browser plug-in or the like)to switch to another channel in the cluster at a lower data rate, say500 kb. To facilitate lookup times, each channel has its associatedcluster ID in its record within the Channel Definition Table. Thisallows the controller unit 440 to easily locate a channel ID, determineits Cluster ID, and find alternate channels. Each Channel Cluster recordpreferably conforms to the following record format: Cluster ID (16-bits)Number of Channels in Cluster (8-bits) Service ID's channels) (16-bits *the number of channels)

[0180] The overall table format for the CT is as

[0181] Table ID

[0182] Number of Clusters

[0183] Cluster Records

[0184] CRC

[0185] (16-bits)

[0186] (8-bits)

[0187] (16-bits * the number of

[0188] follows:

[0189] (8-bit)

[0190] (16-bit)

[0191] (24+(16*the number of channels)*numbers of clusters)

[0192] (16 bit)

[0193] 5. Networking Protocols

[0194] As discussed above, the controller unit 440 may receive Internetrelated protocol messages. It processes such messages and performs thenecessary actions to maintain the controller unit environment. Forexample, when the controller unit 440 receives an IGMP join message froman end-user client application requesting a new service, it may respondwith a predetermined sequence of action. For example, the controllerunit 440 logs the join request, verifies that there is enough bandwidthon the LAN 240 to output the service, and sends an Add Service commandto the appropriate transponder unit 445. The controller unit 440 thensends a response back to the client indicating whether or not the joinwas successful.

[0195] 6. Inter-IPMS Communications

[0196] The controller unit 440 communicates with the transponder units445, and any I/O units that are utilized, through the 10 based-T LAN,shown here at 532. The software of the controller unit 440 maintains aTCP/IP protocol stack to support this interface.

[0197] 7. Serial Communications Over the Modem 470 and RS-232 Port 487

[0198] The controller unit 440 utilizes the monitor and control software490 described above to handle the modem 470 and RS-232 port 487 serialcommunications ports. The serial ports are used to send commands to andfrom the controller unit 440. The commands supported through thisinterface are the same as the commands through the 100 based-T LANinterface 240.

[0199] 8. Command Processor

[0200] Command processor software tasks handle commands that have comein from the various command channels (modem 470, port 487, etc.)supported by the controller unit 440. The commands are parsed andexecuted as needed.

[0201] 9. System Event Logging

[0202] All significant events may be logged into a trace buffer in, forexample, the non-volatile memory (hard drive 455). The controller unitsoftware tasks will take an event, timestamp it, and put the resultingstring into a trace buffer. The software routines may disable individualevents from being put into the log and may control the execution of thelogging process (start, stop, reset, etc.).

[0203] 10. Status Monitoring

[0204] A status-monitoring software task in the controller unit 440monitors the current status of the controller unit 440 and periodicallypolls each of the transponder units 445 for their status. This taskmaintains an image of the current status as well as an image of pastfaults that have occurred since the last time a fault history table wascleared (via command). This task further reports fault and statusinformation to the Network Operations Center 472 over, for example, anInternet connection or modem 470.

[0205] 11. Statistics Gathering

[0206] The statistics gathering task of the controller unit 440 issimilar to the status monitoring software described above. This processkeeps track of the number of users “viewing” a particular channel, theaddresses of users, the number of collisions on the LAN 240, and otherlong term statistics that may be helpful in monitoring the usage of theIPMS 120.

[0207] 12. Power Up Sequence

[0208] The power up sequence software of the controller unit 440 startsall necessary start-up tasks, determines if the transponder units 445need to be programmed, performs all needed power up diagnosticfunctions, and joins the in-band signaling group address of at least ontransponder.

[0209] 13. Dish Pointing Calculation

[0210] The controller unit 440 supports several antenna pointing aids.For example, the controller unit 440 provides a ZIP code to azimuth andelevation calculation. This software application takes a ZIP code as aninput through, for example, the keyboard interface 480, performs thenecessary mathematical calculations or look-up actions, and gives theuser the antenna pointing angles needed to find the satellite signal(azimuth and elevation).

[0211] 14. Interrupts

[0212] The controller unit 440 uses various software routines inresponse to interrupt signals. For example, an interrupt may indicatethat the watchdog timer has expired and, as such, the controller unit440 software begins an orderly soft reset procedure. The controller unit440 also utilizes interrupts to service real time clock, serial portcommunications, parallel port communications, keyboard interfacecommunications, and mouse interface communications. All of theseinterfaces generate interrupts that are handled by the operating system.

[0213] 15. Diagnostics

[0214] The controlling unit software supports multiple forms ofself-diagnostics. Some of the diagnostics run on power up to verifysystem integrity, and other diagnostic functions are run periodicallywhile the controller unit 440 is operational. For example, thecontroller unit 440 initially runs several diagnostics including amemory test, a virus scan, a File Allocation Table (FAT) check, abackplane LAN 532 connectivity test, and an external 100 based-T LAN 240interface test when power is first supplied. As part of its ongoingmonitoring process, the controller unit 440 also performs hard drive 455integrity tests to verify that the file system has not been corrupted.If a hard drive error is encountered, the controller unit 440 logs theerror into its trace history, and tries to correct the problem viadownloading of any corrupted files from the Network Operations Center472. Still further, the controller unit 440 monitors the fault status ofevery transponder unit 445 with which it is associated in the respectiveIPMS 120. The fault monitoring status is an on-going periodic process.All faults are preferably entered into a trace buffer that is availablefor history tracking. Each fault will be time-stamped and stored innon-volatile memory.

[0215] 16. Security

[0216] The software of the controller unit 440 supports multiple levelsof security using passwords. The types of levels of access includes ISPmonitoring, ISP configuration, network operations monitoring, networkoperations configuration, and administrative operations. Each level ofaccess has a unique password. The highest levels of authorization willhave passwords that preferably change periodically. Any changes toeither passwords or configuration settings of the controller unit 440preferably requires a confirmation (either in the form of a Yes/Noresponse or another password).

Command Set for Interfacing with the Controller Unit 440

[0217] As noted above, commands can be provided to the controller unit440 through the RS-232 port 487, the 100 based-T LAN network interfacecard 467, the 10 based-T backplane LAN network interface card 465, orthrough the modem 470. Through the 100 based-T network card 467,commands can be issued either through a SNMP interface, an HTTPinterface, or raw commands through TCP/IP. Exemplary commands are setforth and described below.

[0218] 1. TCP/IP Address

[0219] The TCP/IP address of the IRMS 120 can be set or queried. Thiscommand may be sent from an interface other than the LAN connection(since the LAN connectivity depends on this parameter).

[0220] 2. RS-232 Settings

[0221] The settings for the COM port can be either queried or configuredthrough the command interface.

[0222] 3. Table Download

[0223] The network provisioning tables are downloaded via a tabledownload facility. This command is used to process all new tables andreconfigures the system as necessary. The tables are described above.

[0224] 4. Set Transponder Characteristics (per unit)

[0225] The controller unit 440 keeps track of which transponder unit 445is assigned to each transponder. This implies that the RF parameters ofthe transponder units 445 are maintained and configured through thecontroller unit 440. Once the user has changed a parameter, thecontroller unit 440 forwards the changed information to the transponderunit 445 via the backplane of the LAN 145.

[0226] 5. Network Utilization

[0227] Several statistics are kept on the network utilization, includingthe absolute data rate being output onto the LAN 220 and the numbercollisions being encountered on the LAN 220. The network utilizationstatistics may be made available through a “Network Utilization” querycommand.

[0228] 6. Maximum LAN Data Rate

[0229] The Maximum LAN Data Rate command may be used to limit the amountof bandwidth that the controller unit 440 uses on the LAN 220. Thisallows the ISP to control the maximum impact that the system has on theLAN backbone.

[0230] 7. Current Status

[0231] The controller unit 440 maintains its own internal status and,further, monitors the status of all of the transponder units 445 cardson the LAN 145. The current status of the IPMS 120, and all of itsindividual modules, can be queried through the Current Status Command.

[0232] 8. Card Configuration

[0233] The Card Configuration command is used to query the number oftransponder units 445 in the IPMS 120 and their current settings.

[0234] 9. Usage Statistics

[0235] The Usage Statistics command is used to retrieve the current andpast statistics of the channel usage experienced by the IPMS 120. Thisincludes the number of viewers per channel, the usage of a given channelper time, the

[0236] overall usage of the system per time, and the LAN congestion overtime. All of these statistics may be made available graphically throughan HTTP server or downloaded to the NOC in a binary form using SNMP.

[0237] 10. Trace

[0238] The Trace command is used to start, stop, and configure the tracefunctions of the controller unit 440. Individual events can be enabledor disabled to further customize the trace capabilities of the unit 440.The trace may be uploaded to the Network Operations Center 472 fordiagnostic purposes. The trace data may be stored on the hard drive,which provides a non-volatile record of the events. The maximum size ofthe trace log is determined by the available space on the hard disk and,preferably, can be selected by the user.

[0239] The transponder unit 445 is designed to receive, for example, anL-Band signal off of the satellite 55, convert the signal into itsoriginal digital form, and put the resulting digital signal onto theISP's 100BT LAN 220. Each IPMS 120 may include multiple transponderunits 445 thereby allowing the IPMS 120 to handle significant datatraffic.

[0240]FIG. 18 illustrates various functional blocks of a transponderunit 445. The transponder unit 445 includes an input 550 for receivingan RF signal, such as the L-band signal from satellite 55. The RF signalis supplied from the input 550 to the input of a demodulator 555 thatextracts the digital data from the RF analog signal. The digital datafrom the demodulator 555 is optionally supplied to

[0241] the input of a descrambler 560 that decrypts the data inconformance to the manner in which the data was, if at all, encrypted atthe transmission site.

[0242] One embodiment of a descrambler 560 is illustrated in FIG. 19. Inthe illustrated embodiment, the descrambler 560 may be implemented by afield programmable gate array. One type of field programmable gate arraytechnology suitable for this use is a Lattice ISP 1016.

[0243] The descrambler 560 preferably automatically synchronizes to thestart of a DVB frame marker provided by the demodulator 555. Thedescrambler 560 receives digital data from the demodulator 555 alongdata bus 565, a clock signal along one or more lines 570, and a datavalid signal along one or more lines 575. The data valid signal is usedto qualify the clock signal in the descrambler 560. The descrambler 560of the illustrated embodiment should have the capability of processingfour megabytes/second. Such a processing rate is based on a maximumsystem data rate of 32 bits/second.

[0244] The descrambler 560 is also provided with a microprocessorinterface for programming and monitoring the status of the device by amicroprocessor 580 (see FIG. 18) such as a Motorola 860 type processor.The descrambler 560 preferably supports normal bus access in addition todata transfers through the device into the one packet FIFO. Thedescrambler 560 can also issue an interrupt to the microprocessor 580 torequest immediate service.

[0245] Using a microprocessor interface 585 to the descrambler 560, themicroprocessor 580 is provided with access to the internal registers ofthe descrambler 580 via a bi-directional data bus. The microprocessor580 accesses the device's registers via the address bus of themicroprocessor interface. Preferably, the microprocessor 580 gainsaccess to the registers of the descrambler 560 using a RDNVR signalqualified by a CS signal consistent with the Motorola 860 busarchitecture. The descrambler 560 can also issue an interrupt to the 860processor using INT signal. The microprocessor 580 may also be used toperform overall fuse programming of the descrambler 560 when thedescrambler is implemented using a field programmable gate array.

[0246] The descrambler 560 takes the data received on a data bus 565from the demodulator 555, de-scrambles it in a manner consistent withany scrambling operation performed on the data at the transmission site,and provides it to the input of an HDLC controller 590. In theillustrated embodiment, the descrambler 560 and the HDLC controller 590interface with one another over an HDLC bus 595 that is preferablycomprised of an HDLC parallel data bus, a clock signal, and a controlbus. The HDLC controller 590 serializes the data received on the databus of the HDLC bus 595 and provides it as a serialized output at serialbus 600 for supply at one or more output lines. The serial form of thedata is used by the HDLC controller 590 for validation andde-packetization operations.

[0247] The descrambler 560 may have two modes of operation: a descramblemode and a clear channel mode. In the descramble mode, the devicedescrambles the data to be serialized for the HDLC controller 590.Preferably, the descrambler 560 supports simple P/N sequenceddescrambling. This mode is used as a protected transmission mode thatassists in preventing unauthorized access of the transmissions. In thismode, the descrambler may use, for example, an 8 bit seed used todescramble the input data. This seed is preferably programmed into thedescrambler 560 through the microprocessor interface bus 605. Themicroprocessor 580 may asynchronously set the seed value by writing to aseed register internal to the descrambler 560.

[0248] In the clear channel mode, the descrambler 560 allows the data tobe serialized without de-scrambling. This mode is used for anunprotected transmission mode in which unauthorized receipt of thetransmission is not a significant issue. Clear channel mode can be setby programming the seed register to, for example, all zeros.

[0249] The descrambler 560 may also maintain several counters to allowthe microprocessor to detect system errors. For example, the descrambler560 may store a count of the number of block errors detected. This ispreferably implemented as a 16 bit register that rails (i.e. does notcycle back to zero) at OxFFFF (65,535). The descrambler 560 stores acount of the number of valid packets read from the IF.

[0250] The HDLC controller 590 receives the parallel bit data from thedescrambler and depacketizes the HDLC frames. The HDLC controller 590processes the CRC, removes the flags, and removes any bit stuffingcharacters from the HDLC frame. If there are any errors in the data,they are indicated in the status provided by the HDLC controller 590.Typical errors include CRC errors and frames that are too long. Theresulting data is fed to a FIFO 610 with both start of packet (SOP) andend of packet (EOP) indications. The resulting packets stored in FIFO610 are complete TCP/IP packets that can be output onto the 100 BT LAN220. If a packet contains a CRC error, the packet will be discarded anda packet error counter will be incremented.

[0251] The data from the FIFO 610 is provided to the input of a packetfilter 615. The packet filter 615 is preferably implemented using afield programmable gate array. The packet filter 615 determines whetherthe data packet stored in the FIFO 610 is intended for transmission onthe LAN 220 or is to be discarded. This decision is made by the packetfilter 615 based on whether someone directly connected to the LAN 220 orwho is remotely connected to the LAN 220 has joined the multicast groupto which the packet belongs. The packet filter 615 stores valid packetsinto a single packet FIFO 620 that is used to buffer the packet forprovision to a network interface card, such as an ethernet controller625. The ethernet controller 625 takes the packet from the FIFO 620 andtransmits it onto the LAN 220 through an ethernet transceiver andtransformer using standard ethernet protocols. Such protocols includecollision detection and re-transmission as well as all preamble and CRCgeneration needed. The output of the ethernet controller 625 is fed,using a standard media independent interface (MII) to an ethernettransceiver 630 that converts the digital packet into an ethernet analogsignal.

[0252] A transformer 635 is used to alter the electrical levels of thissignal so that it is compatible with the LAN 220. The microcontroller580 configures and monitors this entire process and reports status, logsfaults, and communicates with external systems via the internal 10-basedT backplane LAN 145. In addition to the backplane LAN 145, thetransponder unit 445 can be controlled through a standard RS-232 port637 that, for example, may be used for debugging the unit.

[0253] Preferably, the packet filter 615 is a TCP/IP filter implementedusing a field programmable gate array. The primary task of the packetfilter 615 is to filter all IP packets received and to pass only validpackets for which a subscriber exists on the network for the multicasttransmission. Other tasks that may optionally be performed by packetfilter 615 are such tasks as IP address translation (see above),notification of the microprocessor of the occurrence of any over flowerrors on the channel, etc.

[0254]FIG. 20 illustrates one embodiment of the packet filter 615 asimplemented by a field programmable gate array 645 and a static RAM 650.The figure also illustrates the relationship between the packet filter615 and other system components. The field programmable gate array maybe one such as is available from XILINX, LATTICE, ALTERA, or other FPGAmanufacturers.

[0255] As illustrated, the packet filter 615 includes a microprocessorinterface 655 comprised of a microprocessor data bus, microprocessoraddress bus, and a microprocessor control bus. The microprocessorinterface 655 provides an interface for programming and monitoring thestatus of the packet filter 615. The device supports normal bus accessin addition to data transfers through the device into the one packetFIFO 610. The packet filter 615 may also issue an interrupt to themicroprocessor 580 to request immediate service.

[0256] The microprocessor 580 accesses the registers of the programmablegate array 645 through the bi-directional data bus of the interface 655.Selection of which of the registers are accessed is performed by themicroprocessor 580 over the address bus of the interface 655. Themicroprocessor 580 gains access to the registers over the control bus ofthe interface 655 using a RDIWR signal that is qualified with a CSsignal consistent with the Motorola 860 bus architecture. Any interruptfrom the packet filter 615 is also provided over the control bus.

[0257] The field programmable gate array 645 also provides an SRAMinterface 660 for interfacing with SRAM 650. This interface is comprisedof a data bus, an address bus, and a control bus. The gate array 645gains access to the registers of the SRAM 650 by selecting theappropriate register over the address bus and providing a OE/WR signalqualified by a CS signal consistent with the SRAM bus architecture.

[0258] The field programmable gate array 645 provides packet flowcontrol between the FIFO 620 and FIFO 610. This control is providedbased on a FIFO interface that includes a data bus 665 and a FIFOcontrol bus 670.

[0259] In the disclosed embodiment, the packet filter 615 is designed tostore up to 64K (65,535) addresses that are used as filter addresses.The LSB (bottom 16 bits) of the 32-bit address field of a packet iscompared to an addresses stored in SRAM 650. The addresses in SRAM 650are stored based on commands received by the packet filter 615 from themicroprocessor 580. These addresses correspond to multicast groupaddresses for which a subscriber on the system has issued a “join”command. If the address of a packet received at FIFO 610 matches ajoined address stored in the SRAM 650, then the entire packet will bepassed to the single packet FIFO 610 and the FPGA 645 will notify theEthernet controller 625 that the data is to be transmitted onto the LAN220. The single packet FIFO 610 is used as temporary storage until theentire TCP/IP packet is processed and transmitted to the ethernetcontroller 625. If a re-transmit is needed, then the single packets FIFO610 is reset and the data can be read again.

[0260] The packet filter 615 auto-synchronizes to the HDLC start offrame marker. This marker is read from the FlFO 620 and the ninth bit isused to signal the FPGA 645 to re-synchronize the internal statemachine.

[0261] In the event that the ethernet controller 625 cannot successfullytransmit the packet stored in the single packet FIFO 610, the packetfilter 615 either initiates a re-transmit cycle or aborts the packet andcontinues with the next available packet. To make this determination,the packet filter 615 queries the FIFO 620 for a half-full status. Ifthe FIFO 620 is more that half fill, then the packet in the singlepacket FlFO 610 is discarded. If the FIFO 620 is more than half full,then the single packet FIFO 610 is placed in a re-transmit mode and thepacket is given another chance for transmission.

[0262] The packet filter 615 may also include a pass-through mode ofoperation. In this mode the packet filter 615 allows the microprocessor580 to write data into the single packet FIFO 610 for application to theethernet controller 625 and, therefrom, for transmission on the LAN 220.This mode may be used to send test packets to the ethernet controller625 and to the client sub-system.

[0263] The packet filter 615 may maintain several counters to allow themicroprocessor 580 to detect system errors. Such counters may include acounter for demodulator block errors, a counter for packet re-transmiterrors, a counter for packet abort errors, a counter for valid packetcount, and a counter for valid address count. Each of these counters maybe reset through commands issued from the microprocessor 580 to thepacket filter 615.

[0264] The demodulator block error counter is used to count the numberof block errors that are detected. This counter may be a 16 bit registerthat rails at OxFFFF.

[0265] The packet re-transmit error counter stores a count of the numberof packets that the packet filter 615 tried to re-transmit. If a packetis retransmitted more than once, each attempt increments the count. Thiscounter is preferably implemented as a 16 bit register that rails atOxFFFF (65,535).

[0266] The packet abort error counter stores a count of the number ofpacket aborts that have occurred. This is the packets that were notsuccessfully transmitted. This is a 16 bit register that rails (i.e. notcycle back to zero) at OxFFFF (65,535).

[0267] The valid packet counter stores a count of the number of validpackets read from FIFO 620 while the valid address counter stores acount of the number of valid TCP/IP addresses received. Each of thesecounters is preferably implemented as a 32 bit register counter.

[0268] Table 1 below describes some of the write registers that may beincluded in the packet filter 615, while Table 2 (below Table 1)describes some of the read registers that may be included. TABLE 1 WRITEREGISTERS REGISTER Size MNEMONIC (bits) Description RAMADDRH 8 SRAMaddress High RAMADDRL 8 SRAM address Low RAMDATA 5 SRAM Data Bit 0 -Filter ON/OFF Bit 1..4 - Translation Address (A15..A12) of the TCP/IPaddress CONTROLREG 8 Miscellaneous control register Bit 0 - Micropass-through mode Bit 1 - Address Translation ON/OFF Bit 2 - unassignedBit 3 - unassigned Bit 4 - unassigned Bit 5 - unassigned Bit 6 -unassigned Bit 7 - unassigned STATREG 8 Status Register Clear Bit 0 -Clear DMERRCNT Bit 1 - Clear RETXCNT Bit 2 - Clear ABORTCNT Bit 3 -Clear PKTCNT Bit 4 - Clear ADDRCNT Bit 5 - unassigned Bit 6 - unassignedBit 7 - unassigned MACADDR0 8 Ethernet Controller Address BYTE 0 (LSB)MACADDR1 8 Ethernet Controller Address BYTE 1 MACADDR2 8 EthernetController Address BYTE 2 MACADDR3 8 Ethernet Controller Address BYTE 3MACADDR4 8 Ethernet Controller Address BYTE 4 MACADDR5 8 EthernetController Address BYTE 5 (MSB)

[0269] TABLE 2 READ REGISTERS REGISTER MNEMONIC Size (bits) DescriptionSTATREG 8 Indicates status of packet filter Bit 0 - Input OVERFLOW BitI - Single Packet FIFO Timeout Bit 2 - Re-Transmit OVERFLOW Bit 3 -unassigned Bit 4 - unassigned Bit 5 - unassigned PKTSTAT 16 Last packettransmitted status DMERRCNT 16 Demodulator Error Count RETXCNT 16Re-Transmit Count ABORTCNT 16 Packets Aborted Count PKTCNT 32 ValidPackets Count ADDRCNT 32 Valid Packets Count

[0270] Table 3 (below) provides an exemplary pin-out listing for thepacket filter 615: TABLE 3 SIZE PIN NAME(S) (BITS) TYPE DESCRIPTIONMICROPROCESSOR INTERFACE DATA 8 Input/ Microprocessor data bus outputADDRESS 4 Input Microprocessor data bus CS 1 Input Microprocessor chipselect RW 1 Input Microprocessor read/write INT 1 Output Microprocessorinterrupt FIFO 620 INTERFACE DATA 8 Input FIFO data input RD 1 OutputFIFO read WR 1 Output FIFO write ERR 1 Input FIFO block error BCLK 1Input FIFO byte clock BLKSTART 1 Input FIFO start of block FULL I InputFIFO full flag HALF 1 Input FIFO half full flag EMPTY 1 Input FIFO emptyflag SRAM INTERFACE ADDRESS 16  O SPAM address DATA 8 I/O SRAM data RW 1Output SRAM read/write OE 1 Input SRAM output enable SINGLE PACKET FIFOINTERFACE DATA 9 Output FIFO data RD I Output FIFO read WR 1 Output FIFOwrite RST 1 Output FIFO reset FULL 1 Input FIFO full flag EMPTY 1 InputFIFO empty flag

[0271] As noted above, the packet filter 615 may allow each filteredaddress to be translated into another IP address. Translation ispreferably only allowed on the upper nibble of the LSB (A15, A14, A13,and A12). The translation bits will be downloaded along with the addressfilter information. Still further, the packet filter 615 preferably usesan FPGA 645 that is capable of being modified by the microprocessor 580.In such instances, the FPGA technology of the FPGA 645 should be chosento allow local re-programming of the FPGA fuse map.

[0272] The FPGA 645 preferably processes at least one mega-words persecond (32 bits per word). If the FPGA 645 is run at 10 MHz, then 10internal cycles can be used in a state machine per word received. Ashutdown relay or other type of physical device may be employed to shutthe 100 based T LAN output off. This may be controlled by themicroprocessor 580 and is preferably tied, via backplane communications,to the Panic Button on a front panel of the system. This relay is notshown in the figures.

[0273] The transponder unit 445 of the disclosed embodiment processes a10 BaseT ethernet connection that necessitates a TCP/IP protocol stack.This stack requirement makes it preferable to use a DRAM in thetransponder unit 445. The stack requirement drives the DRAM memoryrequirements of the unit 445. The DRAM should be large enough to supportthe software (the code will be downloaded into DRAM using a TFTP boot),the RAM variables, and the protocol stacks.

[0274] The transponder unit 445 also preferably includes a batterybacked RAM that maintains a small trace buffer, factory test results,and the card's serial number. The non-volatile memory is preferablyorganized into two identical blocks which are both, individually,subject to CRC checks. Such checks ensure that if a write process isbeing performed and the power is removed, damaging the integrity of theblock, a second backup image of the non-volatile memory will still beintact.

[0275] Each transponder unit 445 preferably includes a test LED, a faultLED, a carrier sync LED, a LAN activity LED, and a LAN collision LED.The test LED is on whenever the unit is performing a test function,including its power up test. The fault LED will be on whenever a majorfault has occurred. The carrier sync LED is activated on whenever the RFsignal received by the transponder unit 445 is being correctlydemodulated and the data is error free.

[0276] The LAN activity LED is activated on whenever the transponderunit 445 is actively outputting a multicast stream onto the 100 based-TLAN. The LAN collision LED indicates a collision has occurred on the 100based-T LAN.

[0277] Transponder Unit Software Operation

[0278] The transponder unit 445 is preferably controlled by an embeddedsoftware application. The software is responsible for configuring thehardware of the transponder unit 445 monitoring all activity of thetransponder unit 445, and processing any backplane communications. Thefollowing sections describe the various interfaces and tasks that thesoftware supports.

[0279] 1. Operating System

[0280] The underlying real time operating system (RTOS) is preferablyVxWorks. VxWorks has been used in embedded processor designs for over 18years and provides a pre-emptive operating environment with anintegrated protocol stack and other types of networking support

[0281] 2. Backplane Host Interface

[0282] The host interface over the backplane is implemented on a 10based-T ethernet LAN 145 and the LAN protocol is TCP/IP. All commandsthat are issued over the backplane LAN 145 are processed identically tocommands received over the RS-232 serial interface 487. The controllerunit 440 transmits commands to the transponder unit 445 over thisinterface. Still further, the controller unit 440 passes commands fromthe NOC 472 to the transponder unit 445. In order, to support thisinterface, the operating system's standard networking protocols areused.

[0283] 3. RS-232 Serial Command Interface

[0284] The serial port 637 is used to provide a diagnostic port that canbe used to send commands to the transponder unit 445. The serial portsoftware processes commands identically to the backplane host interface.

[0285] 4. Command Processor

[0286] The command-processing task parses incoming commands and executesany actions specified by the command.

[0287] The following sections (A-N) describe some example commands thatthe transponder unit 445 supports:

[0288] A. Add Group

[0289] The Add Group command allows the controller unit 440 to enable agroup address to be passed through to the 100 based-T LAN 220. When thiscommand is executed, the microcontroller 640 enables the group's addresswithin the lookup table in the SRAM 650.

[0290] B. Delete Group

[0291] The Delete Group command allows the transponder unit 445 todisable a group address that is currently being passed through to the100 based-T LAN 220. When this command is executed the microcontroller655 disables the group's address within the lookup table in the SRAM650.

[0292] C. Address Route

[0293] The Address Route command is used to change the default IGMPaddress of a particular service or block of services. As describedpreviously, the entire address block allocated to the video from thesatellite can be moved or individual channel addresses can be moved. Thetransponder unit 445 is programmed with an address map and programs theFPGA 650 accordingly.

[0294] D. LAN Shutoff

[0295] The LAN shutoff command activates a relay on the output to the100 based-T LAN 220. The controller unit 440 issues this command whenthe Panic Button has been pressed.

[0296] E. RS-232 Port

[0297] The RS-232 Port command is used to change the communication portparameters. These parameters include the baud rate, parity bit, stopbit, and number of data bit settings for the port.

[0298] F. Boot

[0299] A TFTP process, initiated by the operating system of thetransponder unit 445 will handle the boot process. This process ishandled over the backplane LAN 145.

[0300] G. Status and Fault

[0301] The current status and fault histories can be queried through theStatus and Fault commands. These commands are accessed by the controllerunit 440, the NOC 472, and through the RS-232 port 675 to determine thestatus and fault histories of the transponder unit 445.

[0302] H. Trace

[0303] Similar to the trace command on the controller unit 440, thetrace command of the transponder unit 445 can be used to configure(start, stop, or reset) the trace buffer, or it can be used to query thecontents of a trace buffer. The trace buffer on the transponder unit 445may be implemented to be much smaller than the trace buffer of thecontroller unit 440 so the controller unit 440 accesses data from thetrace buffer of the transponder unit 445 periodically, resetting thetrace after the query is complete.

[0304] I. Set Carrier

[0305] The Set Carrier command is used to set the L-Band frequency anddata rate of the demodulator 555. Once this command has been issued, thetransponder unit 445 begins its acquisition process.

[0306] J. Scrambler Bypass

[0307] The Scrambler Bypass command allows the transponder unit 445 topass data through the system that has not been scrambled at the headend. This mode is used during development, testing, and may be used inoperation.

[0308] K. Reset

[0309] The Reset command allows an external source, such as thecontroller unit 440, the NOC 472, or a terminal attached to the RS-232port to initiate a soft reset on the transponder unit 445.

[0310] L. ID Query

[0311] Each transponder unit 445 will have a unique serial numberassociated with it. The serial number will be stored in non-volatilememory. The ID Query command is used to either query or set the serialnumber. When setting the serial number, the command is preferablysufficiently scrambled to prevent the serial number from beinginadvertently programmed to an incorrect value.

[0312] M. Memory Read and Memory Write

[0313] The Memory Read and Memory Write commands are used primarily fordevelopment and allows any hardware register or memory location to bemanipulated manually. This includes being able to toggle LED's, updatethe seven-segment LED, or other I/O based activities.

[0314] N. Test Mode

[0315] The Test Mode command provides a means of putting variouscomponents of the transponder unit 445 into test modes. For example, onetest mode generates test packets onto the 100 based-T output LAN. Thesepackets include a packet counter which can be used by a clientapplication to determine if the link is experiencing dropped packets.This command may also be used during board level testing with theresults of the production tests stored in nonvolatile memory.

[0316] The transponder unit 445 is also provided with a number ofdiagnostic functions that support both power up and long-term diagnosticfunctions. On power up, all hardware subsystems are tested including theDRAM, the non-volatile memory, communications with the demodulator, andbackplane ethernet connectivity. Long term diagnostic functions includevalidating the code space (CRC check of the code space), validating thenon-volatile memory, and validating backplane connectivity.

[0317] On powering up, the operating system of the transponder unit 445boots from its core from EPROM. After this, the transponder unit 445requests its current version of firmware from the controller unit 440using a Trivial File Transfer Protocol (TFTP). This method of bootingthe transponder unit 445 ensures that all transponder units in the IPMSchassis are running the same version of software. The operating system,as noted above, supports this type of boot procedure. Once the code hasbeen downloaded, the code begins executing.

[0318] The transponder unit 445 also includes a status and faultmonitoring task that keeps track of the current status as well as afault history value that indicates all of the faults that have occurredsince the last time the fault history was cleared. When the status ofthe transponder unit 445 changes, a trace event is logged into thenon-volatile memory of the transponder unit 445 and the controller unit440 is notified that the transponder unit 445 has at least one eventsaved in its non-volatile memory. Since the controller unit 440preferably maintains a much larger trace buffer than the transponderunit 445, the controller unit 440 is responsible for pulling data out ofthe log of the transponder unit 445 prior to overflow thereof.

[0319] The transponder unit 445 also includes an internal watchdogtimer. If the internal watchdog timer has expired, the transponder unit445 assumes that its internal software has reached an unstablecondition. As such, the transponder unit 445 will shutdown all currenttasks and then reset. The reset re-initializes the transponder unit 445and begins a re-boot procedure. The transponder unit 445 will preferablylog this event in non-volatile memory. The controller unit 440recognizes this condition, logs an error, and reconfigures thetransponder unit 445.

[0320] The transponder unit 445 shuts down the outgoing IGMP streamsafter the backplane LAN 145 becomes inoperable for a specified period oftime. If the backplane LAN 145 has become inoperable, the transponderunit 445 assumes that the controller unit 440 has ceased operation.Since the controller unit 440 is responsible for all of the protocolcommunication of the IPMS 120 with external devices, the transponderunit 445 assumes that the controller unit 440 can no longer receive‘leave’ requests from clients. In order to prevent “bombarding’ theclient with potentially unwanted data, the transponder unit 445 willshutdown all outgoing streams.

[0321] Once backplane LAN 145 communications are restored, thetransponder unit 445 will request its current channel mapping and begintransmitting again. The transponder unit 445 logs this event innon-volatile memory.

[0322] Each transponder unit 445 is preferably implemented on a singleprinted circuit card having the ability to be “hot swapped”. In orderfor this to be implemented, the connectors between the printed circuitcard and its corresponding backplane connector include longer pins forthe power and grounds signals such that the transponder unit on theprinted circuit board has power applied to it before output signalsreach the connectors of the backplane bus.

[0323] A “hot sparing” system can also be employed. In such instances,one or more spare transponder units are included in the IPMS 120chassis. The spare transponder units can be configured to take over forfailed transponder units. This configuration procedure will be handledby the controller unit via the backplane LAN 145.

[0324] The IPMS 120 may have several means of helping an installer pointthe antenna. To this end, each transponder unit 445 provides an AGEindication that provides a means of identifying when the satellitesignal is maximized. This indication alone will not necessarily providethe best signal, however, due to different types of interference(adjacent satellite, cross-pole, etc.). Many times the interferenceshould be minimized instead of the signal level being maximized. To aidin this type of decision making, each transponder unit 445 will providean Eb/No reading that indicates the quality of the incoming signal. Thismeasurement should be maximized. The values of these parameters will bepassed to the controller unit 440, which can present them in auser-friendly manner to the installer. This data may also be availablethrough the serial port 637 of the transponder unit 445.

[0325] As also illustrated in FIG. 18, the transponder unit 445 alsoincludes a 10baseT connection to the controller unit. This interfaceincludes an ethernet transceiver 672 and transformer 673. It should befurthered noted that substantially all of the principal units of thetransponder unit 445 communicate with microprocessor 580 over acommunications bus.

[0326] FIGS. 21-26 illustrate various example ISP configurations andscenarios using the IPMS 120 of the present invention. In each scenario,an IP Multicast system application delivers IP multicast streams toInternet Service Providers' (ISPs) clients. The stream content isreceived, for example, over a satellite by the IPMS which is directlyattached to an ISP's local backbone. The stream flows over the localbackbone and through the ISP's networking equipment to the client'sdesktop browser as shown, for example, at arrow 680 of FIG. 21.

[0327] There are a number of goals for each of the following ISPconfigurations and scenarios. They include:

[0328] Delivering streams to clients on demand, and quickly removingthese streams from the ISP backbone when the client is finished

[0329] Delivering streams to clients while minimizing the traffic on thelocal backbone of the ISP;

[0330] Delivering streams to clients while minimizing additional trafficto other clients; and

[0331] Delivering streams to clients while not introducing anyadditional traffic to the Internet.

[0332] Achieving these goals requires that the networking equipmentutilized in the system support various protocol interactions (e.g. IP,IGMP, PIM).

[0333] ISP Model 1—Simple ISP (Simple IPMS 120)

[0334] ISP MODEL 1 is illustrated in FIG. 21. In this example, Client Ajoins, receives, and leaves Multicast Group 239.216.63.248 from the IPMS120. Next, Client A joins and receives Multicast Group 239.216.0.8.Then, network elements query the group so that multicast traffic can bepruned in the event group members silently leave the group. Finally,Client A leaves Multicast Group 239.216.0.8.

[0335] The IPMS 120 filters the multicast stream so that which arecurrently “joined will be placed on the ISP LAN several assumptionsassociated with scenario, they are:

[0336] IPMS 120 IP Address128.0.0.255, Client A1P Address=128.0.0.1;

[0337] All IP Multicast Addresses provided by the IPMS 120 are“Administratively Scoped” addresses in the range 239.216.0.0 through239.219.255.255 (addresses 239.216.0.8 and 239.216.63.248 used in thisexample); and

[0338] IPMS 120, Access Switch/Routers #1 and #2, and Gateway Router 685support IGMP V2.

[0339] During initial handshake, the following occurs:

[0340] 1. Client A sends an IGMP V2 Membership Report (Destination IPaddress=239.216.63.248, Group address=239.216.63.248);

[0341] 2. Access Switch/Router #1 forwards IGMP V2 Membership Report tobackbone LAN 220 (assuming it has no other interfaces in Groupaddress=239.216.63.248);

[0342] 3. Gateway Router does not forward “Administratively Scoped”membership report to the internet;

[0343] 4. IPMS 120 receives IGMP V2 Membership Report and transmits239.216.63.248 multicast onto Filtered Stream—the data payload of the239.216.63.248 multicast includes the IPMS IP Address, and a testpattern;

[0344] 5. Access Switch/Router #1 forwards 239.216.63.248 multicast toClient A only;

[0345] 6. Gateway Router ignores 239.216.63.248 multicast as anadministratively scoped address;

[0346] 7. Client A receives IPMS IP Address and test pattern and thensends an IGMP Leave Group (Destination IP address=224.0.0.2, Groupaddress=239.216.63.248);

[0347] 8. Access Switch/Router #1 verifies it has no other interfaces inGroup address=239.216.63.248 (using IGMP Query), forwards IGMP LeaveGroup to LAN backbone 220, and immediately stops forwarding the239.216.63.248 multicast to Client A;

[0348] 9. Gateway Router 685 ignores IGMP Leave Group command; and

[0349] 10. IPMS 120 receives IGMP Leave Group, verifies it has no otherclients in Group address=239.216.63.248 (using IGMP Query), andimmediately stops transmission of the 239.216.63.248 multicast data.

[0350] When Client A joins Multicast Group 239.216.0.8, the followingoccurs:

[0351] 11. Client A sends an IGMP V2 Membership Report (Destination IPaddress=239.216.0.8, Group address=239.216.0.8);

[0352] 12. Access Switch/Router #1 forwards IGMP V2 Membership Report toLAN backbone 220 (assuming it has no other interfaces in Groupaddress=239.216.0.8);

[0353] 13. Gateway Router ignores IGMP V2 Membership Report for“Administratively Scoped” address;

[0354] 14. IPMS 120 receives IOMP V2 Membership Report and transmits239.216.0.8 multicast onto Filtered Stream;

[0355] 15. Access Switch/Router #1 forwards 239.216.0.8 multicast toClient A only;

[0356] 16. Gateway Router ignores 239.216.0.8 multicast as anadministratively scoped address;

[0357] 17. Client A receives 239.216.0.8 multicast.

[0358] In order to ensure that Client A has not silently left themulticast group, the system implements a querying of the Multicast Group239.216.0.8 based on query timers configured in the access switch/routerand IPMS 120. This query proceeds in the following manner:

[0359] 18. Access Switch/Router #1 sends IGMP Group-Specific Query(Destination IP address=239.216.0.8, Group address=239.216.0.8) toClient A;

[0360] 19. If Access Switch/Router #1 receives an IGMP V2 MembershipReport (Destination IP address=239.216.0.8, Group address=239.216.0.8),do nothing;

[0361] 20. If there is no Membership Report then Access Switch/Router #1sends IGMP Leave Group (Destination IP address=224.0.0.2, Groupaddress=239.216.0.8) to the LAN backbone 220 and immediately stopsforwarding the 239.216.0.8 multicast to all clients (including ClientA); system operation then proceeds with Step 26 below.

[0362] The following steps occur independently:

[0363] 21. IPMS 120 sends IGMP Group-Specific Query (Destination IPaddress=239.216.0.8, Group address=239.216.0.8);

[0364] 22. If IPMS 120 receives an IGMP V2 Membership Report(Destination IP Address=239.216.0.8, Group Address=239.216.0.8) donothing;

[0365] 23. If there is no Membership Report then IPMS 120 immediatelystops transmission of 239.216.0.8 multicast (group left due to noresponse);

[0366] The following sequence of events occur when Client A leaves theMulticast Group 239.216.0.8:

[0367] 24. Client A sends an IGMP Leave Group (Destination IPAddress=224.0.0.2, Group Address=239.216.0.8);

[0368] 25. Access Switch/Router #1 receives IGMP Leave Group, verifiesit has no other interfaces in Group Address=239.216.0.8 (using IGMPQuery), forwards IGMP Leave Group to LAN backbone 220, and immediatelystops forwarding the 239.216.0.8 multicast to Client A;

[0369] 26. Gateway Router ignores IGMP Leave Group command since itinvolves an administratively scoped address;

[0370] 27. IPMS 120 receives IGMP Leave Group, verifies it has no otherClients in Group Address=239.216.0.8 (using IGMP Query), and immediatelystops transmission of 239.216.0.8 multicast.

[0371] ISP Model 2—ISP with Multiple LAN Segments/Multicast StreamsSegmented

[0372] In the example shown in FIG. 22, Client A joins, receives, andleaves Multicast Group 239.216.63.248 to receive a brief multicast fromthe IPMS 120. Next, Client A joins and receives Multicast Group239.216.0.8. Then, network elements query the group so that multicasttraffic can be pruned in the event group members silently leave thegroup. Finally, Client A leaves Multicast Group 239.216.0.8.

[0373] The Simple IPMS 120 filters the Multicast Steam so that onlyMulticast Addresses which are currently ‘joined” will be sent to the LANSwitch. The LAN Switch filters the Multicast Stream sent to each segmentso that only Multicast Addresses which are currently ‘joined” by Clientson a segment will be placed on that segment.

[0374] There are several assumptions associated with the illustratedscenario.

[0375] They are:

[0376] IPMS 120 IP Address=128.0.0.255, Client A1P Address=128.0.0.1;

[0377] All IP Multicast Addresses transmitted by the IPMS 120 are“Administratively Scoped” addresses in the range 239.216.0.0 through239.219.255.255 (addresses 239.216.0.8 and 239.216.63.248 used in thisexample);

[0378] Access Switch/Router, LAN Switch, and IPMS 120 support IGMP V2;

[0379] LAN Switch configuration:

[0380] Virtual LAN#1=LAN Segment #1, Backbone, IPMS 120 Control,Filtered Stream#1

[0381] Virtual LAN#2=LAN Segment #2, Backbone, IPMS 120 Control,Filtered Stream#2

[0382] Gateway Router 690 does not forward IGMP messages with“Administratively Scoped” Multicast addresses (this includes messageswith Dest IP239.*.*.*, and IGMP messages with Dest IP224.0.0.1/224.0.0.2that specify a Group Address=239. * *.*).

[0383] During initial handshake, the following occurs:

[0384] 1. Client A sends an IGMP V2 Membership Report (Destination IPAddress=239.216.63.248, Group Address=239.216.63.248);

[0385] 2. Access Switch/Router #1 forwards IGMP V2 Membership Report toLAN Segment #1 (assuming it has no other interfaces in GroupAddress=239.216.63.248);

[0386] 3. LAN Switch receives IGMP V2 Membership Report, forwards themessage, and enables transmission of 239.216.63.248 multicast to LANSegment #1;

[0387] 4. Gateway Router does not forward “Administratively Scoped”membership report to the Internet;

[0388] 5. IPMS 120 receives IGMP V2 Membership Report and transmits239.216.63.248 multicast out NIC#2 onto Filtered Stream—the data payloadof the 239.216.63.248 multicast includes the IPMS 120 IP Address, and atest pattern;

[0389] 6. LAN Switch forwards 239.216.63.248 multicast to LAN Segment #1only;

[0390] 7. Access Switch/Router #1 forwards 239.216.63.248 multicast toClient A only;

[0391] 8. Client A receives IPMS 120 IP Address and test pattern andthen sends an IGMP Leave Group (Destination IP Address=224.0.0.2, GroupAddress=239.216.63.248);

[0392] 9. Access Switch/Router #1 receives IGMP Leave Group, verifies ithas no other interfaces in Group Address=239.216.63.248 (using IGMPQuery), forwards IGMP Leave Group to LAN Segment #1 and immediatelystops forwarding the 239.216.63.248 multicast to Client A;

[0393] 10. LAN Switch receives IGMP Leave Group, forwards the message,verifies that it has no other LAN Segment #1 Clients in GroupAddress=239.216.63.248 (using IGMP Query), and immediately stopstransmission of 239.216.63.248 multicast to LAN Segment #1;

[0394] 11. Gateway Router ignores IOMP Leave Group since it is anadministratively scoped address;

[0395] 12. IPMS 120 receives IGMP Leave Group, verifies it has no otherclient in Group Address=239.216.63.248 (using IGMP Query), andimmediately stops transmission of the 239.216.63.248 multicast.

[0396] When Client A joins the Multicast Group 239.216.0.8, thefollowing operations occur:

[0397] 13. Client A sends an IGMP V2 Membership Report (Destination IPAddress=239.216.0.8, Group Address=239.216.0.8);

[0398] 14. Access Switch/Router #1 forwards IGMP V2 Membership Report toLAN Segment #1 (assuming it has no other interfaces in GroupAddress=239.216.63.248);

[0399] 15. LAN Switch receives IGMP V2 Membership Report, forwards themessage, and enables transmission of 239.216.0.8 multicast to LANSegment #1;

[0400] 16. Gateway Router ignores IGMP Leave Group since it is anadministratively scoped address;

[0401] 17. IPMS 120 receives IGMP V2 Membership Report and transmits239.216.0.8 multicast out NIC#2 onto Filtered Stream;

[0402] 18. LAN Switch forwards 239.216.0.8 multicast to LAN Segment #1only;

[0403] 19. Access Switch/Router #1 forwards 239.216.0.8 multicast toClient A only; and

[0404] 20. Client A receives 239.216.0.8 multicast.

[0405] In order to ensure that Client A has not silently left themulticast group, the system implements a querying of the Multicast Group239.216.0.8 based on query timers configured in the access switch Irouter and IPMS 120. This query proceeds in the following manner:

[0406] 21. Access Switch/Router #1 sends IOMP Group-Specific Query(Destination IP Address=239.216.0.8, Group Address=239.216.0.8) toClient A;

[0407] 22. If Access Switch/Router #1 receives an IGMP V2 MembershipReport (Destination IP Address=239.216.0.8, Group Address=239.216.0.8),do nothing;

[0408] 23. If there is no Membership Report then Access Switch/Router #1sends IGMP Leave Group (Destination IP Address=224.0.0.2, GroupAddress=239.216.0.8) to LAN Segment #1 and immediately stops forwardingthe 239.216.0.8 multicast to all clients (including Client A); andoperations then proceed at Step 32.

[0409] The following steps occur independently:

[0410] 24. LAN Switch sends IGMP Group-Specific Query (Destination IPaddress 239.216.0.8, Group Address=239.216.0.8) to LAN Segment #1;

[0411] 25. If LAN Switch receives IGMP V2 Membership Report (DestinationIP Address=239.216.0.8, Group Address=239.216.0.8) do nothing;

[0412] 26. If there is no Membership Report then LAN Switch sends IGMPLeave Group (Destination IP Address=224.0.0.2, GroupAddress=239.216.0.8) to IPMS 120 and immediately stops transmission of239.216.0.8 multicast to LAN Segment #1 (group is left due to noresponse);

[0413] 27. IPMS 120 sends IGMP Group-Specific Query (Destination IPAddress=239.216.0.8, Group Address=239.216.0.8);

[0414] 28. If IPMS 120 receives IOMP V2 Membership Report (DestinationIP Address=239.216.0.8, Group Address=239.216.0.8), do nothing; and

[0415] 29. If there is no Membership Report then IPMS 120 immediatelystops transmission of 239.216.0.8 multicast (group left due to noresponse).

[0416] The following sequence of events occur when Client A leaves theMulticast Group 239.216.0.8:

[0417] 30. Client A sends an IGMP Leave Group (Destination IPAddress=224.0.0.2, Group Address=239.216.0.8);

[0418] 31. Access Switch/Router #1 receives IOMP Leave Group, verifiesit has no other interfaces in Group Address=239.216.0.8 (using IGMPQuery), and forwards IGMP Leave Group to LAN Segment #1 and immediatelystops forwarding the 239.216.0.8 multicast to Client A;

[0419] 32. LAN Switch receives IGMP Leave Group, forwards the message,verifies it has no other LAN Segment #1 Clients in GroupAddress=239.216.0.8 (using IGMP Query), and immediately stopstransmission of 239.216.0.8 multicast to LAN Segment #1;

[0420] 33. Gateway Router ignores IOMP Leave Group since it is anadministratively scoped address;

[0421] 34. IPMS 120 receives IGMP Leave Group, verifies it has no otherClients in Group Address=239.216.0.8 (using IGMP Query), and immediatelystops transmission of 239.216.0.8 multicast.

[0422] ISP Model 3—Large ISP with Affiliated ISP

[0423] The system of FIG. 23 provides multicast streams to all ISPClients and Remote ISP Clients on demand. In this example, Remote LSDClient H joins, receives, and leaves Group 239.216.63.248 to receive abrief multicast from the IPMS 120. Next, Client H joins and receivesMulticast Group 239.216.0.8. Then, network elements query the group sothat multicast traffic can be pruned in the event group members silentlyleave the group. Finally, Client H leaves Multicast Group 239.216.0.8.

[0424] The Simple IPMS 120 filters the Multicast Stream so that onlymulticast addresses that are currently joined” will be sent to the LANSwitch 695. The LAN Switch 695 filters the multicast stream sent to eachsegment so that only multicast addresses which are currently ‘joined” byclients on a LAN segment will be placed on the LAN segment. For theRemote ISP, the multicast streams do not use bandwidth on the Routerlink to the ISP (to avoid impacting normal Internet traffic).Accordingly, a bridged connection 700 is used to send the streams to theRemote ISP. The only segments that receive the multicast streams are LANSegment #1 and the bridged connection 700 to the Remote ISP that isconsidered to be LAN Segment #2.

[0425] There are several assumptions associated with the illustratedscenario, such as, for example:

[0426] IPMS 120 IP Address=128.0.0.255, Client H IP Address=128.0.0.8;

[0427] All IP Multicast Addresses transmitted by the IPMS 120 are“Administratively Scoped’ addresses in the range 239.216.0.0 through239.219.255.255 (addresses 239.216.0.8 and 239.216.63.248 used in thisexample);

[0428] Access Switch/Routers, LAN Switches, and IPMS 120 support IGMPV2;

[0429] LAN Switch configuration: Virtual LAN#1=LAN Segment #1, Backbone,IPMS 120 Control, Filtered Stream#1; Virtual LAN#2=LAN Segment #2, IPMS120 Control, Filtered Stream#2; and virtual LAN#3=LAN Segment #3,Backbone.

[0430] LAN Bridge configuration: Only forward239.216.0.0-239.219.255.255; 224.0.0.1, 224.0.0.2;

[0431] Remote Router does not forward IGMP messages with“Administratively Scoped” Multicast addresses (this includes messageswith Destination IP=239.*.*.*, and IGMP messages with DestinationIP=224.0.0.1/224.0.0.2 that specify a Group Address=239.*.* *)

[0432] During initial handshake, the following occurs:

[0433] 1. Client H sends an IGMP V2 Membership Report (Destination IPAddress=239.216.63.248, Group Address=239.216.63.248);

[0434] 2. Access Switch/Router #2 forwards IGMP V2 Membership Report toRemote Backbone (assuming it has no other interfaces in GroupAddress=239.216.63.248) seminal LAN Bridge forwards IGMP V2 MembershipReport;

[0435] 3. Remote Router ignores IGMP V2 Membership Report as anadministratively scoped address

[0436] 4. LAN Switch receives IOMP V2 Membership Report, forwards themessage, and enables transmission of 239.216.63.248 multicast to LANSegment #2.

[0437] 5. IPMS 120 receives IGMP V2 Membership Report and transmits239.216.63.248 multicast out NIC#2 onto Filtered Stream—the data payloadof the 239.216.63.248 multicast includes the IPMS 120 IP Address, and atest pattern;

[0438] 6. LAN Switch forwards 239.216.63.248 multicast to LAN Segment #2only;

[0439] 7. LAN Bridge forwards the 239.216.63.248 multicast data;

[0440] 8. Access Switch/Router #2 forwards 239.216.63.248 multicast toClient H only;

[0441] 9. Remote Router ignores 239.216.63.248 multicast data;

[0442] 10. Client H receives IPMS 120 IP Address and test pattern andthen sends an IGMP Leave Group (Destination IP Address=224.0.0.2, GroupAddress=239.21 6.63.248);

[0443] 11. Access Switch/Router #2 receives IGMP Leave Group, verifiesit has no other interfaces in Group Address=239.216.63.248 (using IGMPQuery),

[0444] 12. Forwards IGMP Leave Group to LAN Bridge, and immediatelystops forwarding the 239.216.63.248 multicast to Client H;

[0445] 13. LAN Bridge forwards IGMP Leave Group;

[0446] 14.Remote Router ignores IGMP Leave Group as an administrativelyscoped address

[0447] 15. LAN Switch receives IGMP Leave Group, forwards the message,verifies it has no other LAN Segment #2 Clients in GroupAddress=239.216.63.248 (using IOMP Query), and immediately stopstransmission of 239.216.63.248 multicast to LAN Segment #2;

[0448] 16. IPMS 120 receives IGMP Leave Group, verifies it has no otherClients in Group Address=239.216.63.248 (using IGMP Query), andimmediately stops transmission of the 239.216.63.248 multicast;

[0449] When Client H joins the Multicast Group 239.216.0.8, thefollowing actions occur:

[0450] 17. Client H sends an IGMP V2 Membership Report (Destination IPAddress=239.216.0.8.Group Address=239.216.0.8);

[0451] 18. Access Switch Router #2 forwards IGMP V2 Membership Report toRemote Backbone (assuming it has no other interfaces in GroupAddress=239.21 6.0.8);

[0452] 19. LAN Bridge forwards IGMP V2 Membership Report;

[0453] 20. Remote Router ignores IGMP V2 Membership Report as anadministratively scoped address;

[0454] 21. LAN Switch receives IOMP V2 Membership Report, forwards themessage, and enables transmission of 239.216.0.8 multicast to LANSegment #2;

[0455] 22. IPMS 120 receives IGMP V2 Membership Report and transmits239.216.0.8 multicast out NIC#2 onto Filtered Stream;

[0456] 23. LAN Switch forwards 239.216.0.8 multicast to LAN Segment #2only;

[0457] 24. LAN Bridge forwards the 239.216.0.8 multicast;

[0458] 25. Access Switch/Router #2 forwards 239.216.0.8 multicast toClient H only;

[0459] 26. Remote Router ignores 239.216.0.8 multicast

[0460] 27. Client H receives 239.216.0.8 multicast.

[0461] In order to ensure that Client H has not silently left themulticast group, the system implements a querying of the Multicast Group239.216.0.8 based on query timers configured in the access switch Irouter and IPMS 120. This query proceeds in the following manner:

[0462] 28. Access Switch/Router #2 sends IGMP Group-Specific Query(Destination IP address=239.216.0.8, Group Address=239.216.0.8) toClient H;

[0463] 29. If Access Switch/Router #2 receives an IGMP V2 MembershipReport (Destination IP Address=239.216.0.8, Group Address=239.216.0.8),do nothing;

[0464] 30. If there is no Membership Report then Access Switch/Router #2sends JGMP:

[0465] Leave Group (Destination IP Address=224.0.0.2, GroupAddress=239.216.0.8) to Remote Backbone and immediately stops forwardingthe 239.216.0.8 multicast to Client H; operations then proceed to Step40.

[0466] The following steps occur independently:

[0467] 31. LAN Switch sends IGMP Group-Specific Query (Destination IPAddress 239.216.0.8, Group Address=239.216.0.8) to LAN Segment #2;

[0468] 32. LAN Bridge forwards IGMP Group-Specific Query;

[0469] 33. If LAN Switch receives an IGMP V2 Membership Report(Destination IP Address=239.216.0.8, Group Address=239.216.0.8), donothing;

[0470] 34. If there is no Membership Report then LAN Switch immediatelystops transmission of 239.216.0.8 multicast to LAN Segment #2 (group isleft due to no response);

[0471] 35. IPMS 120 sends IGMP Group-Specific Query (Destination IPAddress=239.216.0.8, Group Address=239.216.0.8)

[0472] 36. If IPMS 120 receives IGMP V2 Membership Report (DestinationIP Address=239.216.0.8, Group Address=239.216.0.8), do nothing;

[0473] 37. If there is no Membership Report then IPMS 120 immediatelystops transmission of 239.216.0.8 multicast (group left due to noresponse).

[0474] The following sequence of operations occur when Client H leavesGroup address=239.216.0.8:

[0475] 38. Client H sends an IGMP Leave Group (Destination IPAddress=224.0.0.2, Group Address=239.216.0.8);

[0476] 39. Access Switch/Router #2 receives IGMP Leave Group, verifiesit has no other interfaces in Group Address=239.216,0.8 (using IGMPQuery), and forwards IGMP Leave Group to Remote Backbone and immediatelystops forwarding the 239.216.0.8 multicast to Client H′

[0477] 40. LAN Bridge forwards IGMP Leave Group;

[0478] 41. Remote Router ignores IOMP Leave Group since it is anadministratively scoped address;

[0479] 42. LAN Switch receives the IGMP Leave Group command, forwardsthe message, verifies it has no other LAN Segment #2 Clients in GroupAddress=239.216.0.8, and immediately stops transmission of 239.216.0.8multicast to LAN Segment #2;

[0480] 43. IPMS 120 receives IOMP Leave Group, verifies it has no otherClients in Group Address=239.216.0.8 (using IGMP Query), and immediatelystops transmission of the 239.216.0.8 multicast.

[0481] If Remote Clients join “normal” multicast groups (i.e., thosetransmitted over the backbone of the Internet) through the RemoteRouter, the 224.0.0.1 and 224.0.0.2 IGMP V2 messages will be bridged tothe LAN Switch. The LAN Switch forwards the IGMP messages through LANsegment #2 to the IPMS 120. The IPMS 120 ignores the messages issued fora non-existent stream.

[0482] ISP Model 4—Simple ISP Scenario 2

[0483] In the scenario of FIG. 24, Client A and the IPMS 120 first joinMulticast Group 239.216.63.240 to establish a mechanism for sendingmulticast control messages to each other. Next, Client A joins,receives, and leaves Multicast Group 239.216.63.248 to receive a briefmulticast from the IPMS 120. After that, Client A joins and receivesMulticast Group 239.216.0.8. Then, network elements query the group sothat multicast traffic can be pruned in the event group members silentlyleave the group. Finally, Client A leaves Multicast Group 239.216.0.8.As above, IPMS 120 filters the multicast stream so that only multicastaddresses which are currently ‘joined’ are provided on the backbone ofthe LAN.

[0484] In this scenario, several assumptions have been made. They are:

[0485] IPMS 120 IP Address=128.0.0.255, Client A IPAddress=128.0.0.1;

[0486] All IP Multicast Addresses transmitted by the IPMS 120 are“Administratively Scoped” addresses in the range 239.216.0.0 through239.219.255.255 (addresses 239.216.0.8, 239.216.63.24 through239.216.63.248 being used in this example);

[0487] IPMS 120, Access Switch/Routers, and Gateway Router support IGMPV2 protocol;

[0488] The IPMS 120 and the clients use MulticastAddress=239.216.63.240to pass proprietary UDP packets using UDP Port=255.

[0489] The following operations occur during initial handshake:

[0490] 1. IPMS 120 sends an IGMP V2 Membership Report (Destination PAddress=239.216.63.240, Group Address 239.216.63.240);

[0491] 2. The 239.216.63.240 multicast will be used for multicastcontrol messages;

[0492] 3. Gateway Router does not forward “Administratively Scoped’membership report to the Internet;

[0493] 4. Client A sends an IGMP V2 Membership Report (Destination IPAddress=239.216.63.240, Group Address=239.216.63.240);

[0494] 5. Access Switch/Router #1 forwards IOMP V2 Membership Report toLAN Segment#1 (assuming it has no other interfaces in GroupAddress=239.216.63.240);

[0495] 6. LAN Switch receives IGMP V2 Membership Report, forwards themessage, and adds Client A to the Group;

[0496] 7. Gateway Router does not forward “Administratively Scoped”membership report to the Internet;

[0497] 8. IPMS 120 receives IGMP V2 Membership Report; the239.216.63.240 multicast will be used for multicast control messages;

[0498] 9. Client A sends an IOMP V2 Membership Report (Destination IPAddress=239.216.63.248, Group Address239.216.63.248);

[0499] 10. Access Switch/Router #1 forwards IGMP V2 Membership Report tobackbone (assuming it has no other interfaces in GroupAddress=239.216.63.248);

[0500] 11. Gateway Router does not forward “Administratively Scoped”membership report to the Internet;

[0501] 12. IPMS 120 receives IGMP V2 Membership Report and transmits239.216.63.248 multicast out NIC#2 onto Filtered Stream—the data payloadof the 239.216.63.248 multicast includes the IPMS 120 P Address, and atest pattern;

[0502] 13. Access Switch/Router #1 forwards 239.216.63.248 multicast toClient A only;

[0503] 14. Gateway Router ignores 239.216.63.248 multicast since it isan Administratively scoped address;

[0504] 15. Client A receives IPMS 120 IP Address and test pattern andthen sends an IGMP Leave Group (Destination IP Address=224.0.0.2, GroupAddress=239.216.63.248);

[0505] 16. Access Switch/Router #1 verifies it has no other interfacesin Group Address=239.216.63.248 (using IGMP Query), forwards IGMP LeaveGroup to backbone, and immediately stops forwarding the 239.216.63.248multicast to Client A;

[0506] 17. Gateway Router ignores IGMP Leave Group command since it ison an administratively scoped address;

[0507] 18. IPMS 120 receives IGMP Leave Group, verifies it has no otherClients in Group Address=239.216.63.248 (using IGMP Query), andimmediately stops transmission of the 239.216.63.248 multicast;

[0508] 19. Client A sends a UDP packet (Destination IPAddress=128.0.0.255, Port=255) to the IPMS 120;

[0509] 20. Access Switch/Router #1 forwards UDP packet to backbone;

[0510] 21. Gateway Router does not forward packet to Internet since itis destined for a local administratively scoped address;

[0511] 22. IPMS 120 receives UDP packet and sends UDP packet(Destination IP Address=128.0.0.1, Port=255);

[0512] 23. Gateway Router does not forward packet to Internet since itis destined for a local administratively scoped address;

[0513] 24. Access Switch/Router #1 forwards UDP packet to Client A;

[0514] 25. Client A receives UDP packet.

[0515] The following operations occur when Client A joins MulticastGroup 239.216.0.8:

[0516] 26. Client A sends an IGMP V2 Membership Report (Destination IPAddress=239.216.0.8, Group Address=239.216.0.8);

[0517] 27. Access Switch/Router #1 forwards IGMP V2 Membership Report tothe LAN backbone (assuming it has no other interfaces in GroupAddress=239.216.63.248);

[0518] 28. Gateway Router ignores IGMP V2 Membership Report since it isan administratively scoped address;

[0519] 29. IPMS 120 receives IGMP V2 Membership Report and transmits239.216.0.8 multicast out NIC#2 onto Filtered Stream;

[0520] 30. Access Switch/Router #1 forwards 239.216.0.8 multicast toClient A only;

[0521] 31. Gateway Router ignores 239.216.0.8 multicast(“Administratively Scoped” address);

[0522] 32. Client A receives 239.216.0.8 multicast.

[0523] The following query operations ensure that the IPMS 120 does nottransmit a Multicast Group that a client has silently left:

[0524] 33. Access Switch/Router #1 sends IGMP Group-Specific Query(Destination IP Address=239.216.0.8, Group Address=239.216.0.8) toClient A

[0525] 34. If Access Switch/Router #1 receives an IGMP V2 MembershipReport (Destination IP Address=239.216.0.8, Group Address=239.216.0.8),do nothing;

[0526] 35. If there is no Membership Report then Access Switch/Router #1sends IGMP Leave Group (Destination IP Address=224.0.0.2, GroupAddress=239.216.0.8) to backbone and immediately stops forwarding the239.216.0.8) multicast to all Clients (including Client A); operationsthen proceed at Step 40;

[0527] 36. IPMS 120 sends UDP packet (Destination IPAddress=239.216.63.240, Port=255);

[0528] 37. Client A receives UDP packet and responds with UDP packet(Destination IP Address=239.216.63.240, Port=255) (other Clients willreceive and ignore this packet);

[0529] 38. lf IPMS 120 receives no UDP response, then it immediatelystops forwarding the 239.216.0.8 to all Clients (group left due to noresponse).

[0530] The following operations occur when Client A purposely leaves theGroup;

[0531] 39. Client A sends an IGMP Leave Group (Destination IPAddress=224.0.0.2, Group Address=239.216.0.8);

[0532] 40. Access Switch/Router #1 receives IGMP Leave Group, verifiesit has no other interfaces in Group Address=239.216.0.8 (using IGMPQuery), forwards IOMP Leave Group command to the LAN backbone, andimmediately stops forwarding the 239.216.0.8 multicast to Client A;

[0533] 41. Gateway Router ignores the IGMP Leave Group command since itis directed on an administratively scoped address;

[0534] 42. IPMS 120 receives the IGMP Leave Group command, verifies ithas no other Clients in Group Address=239.216.0.8 (using IGMP Query),and immediately stops transmission of 239.216.0.8 multicast.

[0535] The following handshake operations occur during finaltermination:

[0536] 43. Client A sends a UDP packet (Destination IPAddress=128.0.0.255, Port=255) to the IPMS 120

[0537] 44. Access Switch/Router #1 forwards UDP packet to backbone;

[0538] 45. Gateway Router ignores the message since it is routedlocally;

[0539] 46. IPMS 120 receives the UDP packet and sends a UDP packet(Destination IP Address=128.0.0.1, Port=255) to Client A;

[0540] 47. Gateway Router ignores message routed locally;

[0541] 48. Access Switch/Router #1 forwards the UDP packet to Client A;

[0542] 49. Client A receives UDP packet.

[0543] ISP Model 5—ISP with Multiple LAN Segments/Multicast StreamsSegmented—Scenario 2

[0544] In the example of FIG. 25, Client A and the IPMS 120 first joinMulticast Group 239.216.63.240 to establish a mechanism for sendingmulticast control messages to each other. Next, Client A joins,receives, and leaves Multicast Group 239.216.63.248 to receive a briefmulticast from the IPMS 120. After that, Client A joins and receivesMulticast Group 239.216.0.8. Then, network elements query the group sothat multicast traffic can be pruned in the event group members silentlyleave the group. Finally, Client A leaves Multicast Group 239.216.0.8.

[0545] The IPMS 120 filters the multicast streams sent to each segmentso that only multicast addresses which are currently “joined” will besent to the LAN Switch per segment. This implies that the LAN switchdoes not have to support IGMP V2, although this provision is notmandatory.

[0546] In the scenario of FIG. 25, the following assumptions have beenmade:

[0547] IPMS 120 IP Address=128.0.0.255, Client A IP Address=128.0.0.1;

[0548] All IP Multicast Addresses transmitted by the IPMS 120 are“Administratively Scoped” addresses in the range 239.216.0.0 through239.219.255.255 (addresses 239.216.0.8, 239.216.63.240, 239.216.63.248used in this example);

[0549] Access Switch/Routers and IPMS 120 support IGMP V2;

[0550] LAN Switch may or may not support IGMP V2;

[0551] LAN Switch configuration:

[0552] Virtual LAN#1=LAN Segment#1, Backbone, IPMS 120 Control, FilteredStream#1;

[0553] Virtual LAN#2=LAN Segment #2, Backbone, IPMS 120 Control,Filtered Stream#2

[0554] Remote Router does not forward IGMP messages with“Administratively Scoped’” Multicast addresses (this includes messageswith Dest IP=239.*.*.*, and IGMP messages with DestIP=224.0.0.1/224.0.0.2 that specify a Group Address=239.*.*.*);

[0555] The IPMS 120 and the Clients use Multicast Address=239.216.63.240to pass proprietary UDP packets using UDP Port=255.

[0556] The following operations occur during initial handshake in thesystem:

[0557] 1. IPMS 120 sends an IOMP V2 Membership Report (Destination IPAddress=239.216.63.240, Group Address=239.216.63.240);

[0558] 2. LAN Switch receives IOMP V2 Membership Report, forwards themessage, and adds the IPMS 120 to the Group, the 239.216.63.240multicast being used for multicast control messages;

[0559] 3. Gateway Router does not forward the administratively scopedmembership report to the Internet;

[0560] 4. Client A sends an IGMP V2 Membership Report (Destination IPAddress=239.216.63.240, Group Address=239.216.63.240);

[0561] 5. Access Switch/Router #1 forwards IGMP V2 Membership Report toLAN Segment #1 (assuming it has no other interfaces in GroupAddress=239.216.63.240);

[0562] 6. LAN Switch receives IGMP V2 Membership Report, forwards themessage, and adds Client A to the Group;

[0563] 7. Gateway Router does not forward the administratively scopedmembership report to the Internet;

[0564] 8. IPMS 120 receives IGMP V2 Membership Report, the239.216.63.240 multicast being used for multicast control messages;

[0565] 9. Client A sends an IGMP V2 Membership Report (Destination IPAddress=239.216.63.248, Group Address=239.216.63.248);

[0566] 10. Access Switch/Router #1 forwards IGMP V2 Membership Report toLAN Segment #1 (assuming it has no other interfaces in GroupAddress=239.216.63.248);

[0567] 11. LAN Switch receives IGMP V2 Membership Report and forwardsthe message;

[0568] 12. Gateway Router does not forward the administratively scopedmembership report to the Internet;

[0569] 13. IPMS 120 receives IGMP V2 Membership Report and transmits239.216.63.248 multicast out NIC#2 and NIC#3 onto Filtered Streams 1 and2- the data payload of the 239.216.63.248 multicast includes the IPMS120 IP Address, and a test pattern;

[0570] 14. If LAN Switch is IGMP V2 enabled, it will forward239.216.63.248 multicast to LAN Segment #1 only. If it isn't, then the239.216.63.248 multicast will be forwarded to both LAN Segment #1 andLAN Segment #2;

[0571] 15. Access Switch/Router #1 forwards 239.216.63.248 multicast toClient A only;

[0572] 16. Client A receives IPMS 120 IP Address and test pattern andthen sends an IGMP Leave Group (Destination IP Address=224.0.0.2 GroupAddress=239.216.63.248);

[0573] 17. Access Switch/Router #1 receives IGMP Leave Group, verifiesit has no other interfaces in Group Address239.216.63.248 (using IGMPQuery), forwards IGMP Leave Group to LAN Segment #1, and immediatelystops forwarding the 239.216.63.248 multicast to Client A:

[0574] 18. LAN Switch receives the IGMP Leave Group and forwards themessage. If it is IGMP V2 enabled, it will verify it has no other LANSegment #1 Clients in Group Address=239.216.63.248 (using IGMP Query),and immediately stop transmission of 239.216.63.248 multicast to LANSegment #1;

[0575] 19. Gateway Router ignores IOMP Leave Group since it is on anadministratively scoped address;

[0576] 20. IPMS 120 receives IGMP Leave Group, verifies it has no otherClients in Group Address=239.216.63.248, and immediately stopstransmission of the 239.216.63.248 multicast;

[0577] 32. IPMS 120 receives IGMP V2 Membership Report and transmits239.216.0.8 multicast out NIC#2 onto Filtered Stream #1;

[0578] 33. LAN Switch forwards 239.216.0.8 multicast to LAN Segment #1only;

[0579] 34. Access Switch/Router #1 forwards 239.216.0.8 multicast toClient A only;

[0580] 35. Client A receives 239.216.0.8 multicast.

[0581] The following query operations occur to ensure that the IPMS doesnot unnecessarily provide a Group multicast transmission when there areno subscribers;

[0582] 36. Access Switch/Router #1 sends IGMP Group-Specific Query(Destination IP Address=239.216.0.8, Group Address=239.216.0.8) toClient A;

[0583] 37. If Access Switch/Router #1 receives an IGMP V2 MembershipReport (Destination IP Address=239.216.0.8, Group Address239.216.0.8),do nothing;

[0584] 38. If there is no Membership Report, then Access Switch/Router#1 sends IGMP Leave Group (Destination IP Address=224.0.0.2, GroupAddress=239.216.0.8) to LAN Segment #1 and immediately stops forwardingthe 239.216.0.8 multicast to all clients (including Client A);operations then proceed from Step 53;

[0585] 39. IPMS 120 sends UDP packet (Destination IPAddress=239.216.63.240, Port=255) from NIC #1;

[0586] 40. If LAN Switch is IGMP V2 enabled, it will forward the packetto all interfaces currently monitoring the 239.216.63.240 stream. If itis not IGMP V2 enabled, the packet will be forwarded to all LANinterfaces.

[0587] 41. Gateway Router will ignore the administratively scopedpacket;

[0588] 42. Access Switch/Routers will forward the packet to all Clientslistening to the 239.216.63.240 stream;

[0589] 43. Client A will respond with a UDP packet (Destination IPAddress=239.216.63.240, Port=255);

[0590] 44. The packet will be forwarded by Access/Switch Router #1 toLAN Segment #1;

[0591] 45. The LAN Switch will forward the packet to the IPMS 120 NIC#1;

[0592] 46. Gateway Router will ignore the administratively scopedpacket;

[0593] 47. If IPMS 120 receives no UDP response, then it immediatelystops forwarding the 239.216.0.8 to all Clients (group is left due to noresponse); Independently, if the LAN Switch is IGMP V2 enabled, thefollowing operations occur:

[0594] 48. LAN Switch sends IGMP Group-Specific Query (Destination IPAddress=239.216.0.8, Group Address=239.216.0.8) to LAN Segment #1;

[0595] 49. If LAN Switch receives IGMP V2 Membership Report (DestinationIP Address=239.216.0.8, Group Address=239.216.0.8), do nothing;

[0596] 50. If there is no Membership Report then LAN Switch sends IGMPLeave Group (Destination IP Address=224.0.0.2, GroupAddress=239.216.0.8) to IPMS 120 and immediately stops transmission of239.216.0.8 multicast to LAN Segment #1 (group is left due to noresponse);

[0597] The following operations occur when Client A leaves Group Address239.216.0.8:

[0598] 51. Client A sends an IGMP Leave Group (Destination IPAddress=224.0.0.2, Group Address=239.216.0.8);

[0599] 52. Access Switch/Router #1 receives IGMP Leave Group, verifiesit has no other interfaces in Group Address=239.216.0.8 (using IGMPQuery), forwards IGMP Leave Group to LAN Segment #1, and immediatelystops forwarding the 239.216.0.8 multi cast to Client A;

[0600] 53. LAN Switch receives IGMP Leave Group and forwards themessage. If it is IGMP V2 enabled it verifies it has no other LANSegment #1 Clients in Group address 239.216.0.8 (using IGMP Query), andimmediately stops transmission of 239.216.0.8 multicast to LAN Segment#1;

[0601] 54. Gateway Router ignores IGMP Leave Group since it is in anadministratively scoped address packet;

[0602] 55. IPMS 120 receives IGMP Leave Group, verifies it has no otherClients in Group Address=239.216.0.8, and immediately stops transmissionof 239.216.0.8 multicast.

[0603] The following termination handshake operations occur upontermination of the multicast subscription:

[0604] 56. Client A sends a UDP packet (Destination IPAddress=128.0.0.255, Port=255) to the IPMS 120;

[0605] 57. Access Switch/Router #1 forwards UDP packet to LAN Segment#1;

[0606] 58. LAN Switch forwards packet to IPMS 120 NIC #1;

[0607] 59. IPMS 120 receives UDP packet and sends a UDP packet(Destination IP Address=28.0.0.1, Port=255) to Client A;

[0608] 60. LAN Switch forwards packet to LAN Segment #1;

[0609] 61. Gateway Router will ignore the administratively scopedpacket;

[0610] 62. Access Switch/Router #1 forwards packet to Clients A;

[0611] 63. Client A receives UDP packet.

[0612] ISP Model 6—Large ISP with Affiliated ISP—Scenario 2

[0613] In the example of FIG. 26, Remote Client H and the IPMS 120 firstjoin Multicast Group 239.216.63.240 to establish a mechanism for sendingmulticast control messages to each other. Next, Remote Client H joins,receives, and leaves Multicast Address 239.216.63.248 to receive a briefmulticast from the IPMS 120. After that, Client H joins and receivesMulticast Group 239.216.0.8. Then, network elements query the group sothat multicast traffic can be pruned in the event group members silentlyleave the group. Finally, Client H leaves Multicast Group 239.216.0.8.

[0614] The IPMS 120 filters the multicast streams sent to each segmentso that only multicast addresses that are currently “joined” will besent to the LAN Switch per segment. This implies that the LAN switchdoes not have to support IGMP V2, although this is not necessary. TheLAN Switch may filter the multicast stream sent to each segment so thatonly multicast addresses which are currently “joined” by plans on asegment will be placed on the segment. For the Remote ISP, the multicaststreams preferably to not use bandwidth on the Router link to the ISP(to avoid impacting normal Internet traffic). Rather, a bridgedconnection is used to send the streams to the Remote ISP. The onlysegments that receive the multicast streams are LAN Segment #1 and thebridged connection to the Remote ISP that is considered to be LANSegment #2.

[0615] In this scenario, the following assumptions have been made:

[0616] IPMS 120 IP Address 28.0.0.255, Client A IP Address=128.0.0.1;

[0617] All IP Multicast Addresses transmitted by the IPMS 120 are“Administratively Scoped” addresses in the range 239.216.0.0 through239.219.255.255 (addresses 239.216.0.8, 239.216.63.240, 239.216.63.248used in this example);

[0618] Access Switch/Router and IPMS 120 support IGMP V2:

[0619] LAN Switch may or may not support IGMP V2;

[0620] LAN Switch configuration:

[0621] Virtual LAN#1 LAN Segment #1 Backbone, IPMS 120 Control, FilteredStream#1;

[0622] Virtual LAN#2=LAN Segment #2, IPMS 120 Control, FilteredStream#2;

[0623] Virtual LAN#3 LAN Segment #3, Backbone;

[0624] LAN Bridge configuration: Only forward239.216.0.0-239.219.255.255; 224.0.0.1,224.0.0.2;

[0625] Remote Router does not forward IGMP messages with“Administratively Scoped” Multicast addresses (this includes messageswith Dest IP239.*.*.*, and IGMP messages with DestIP=224.0.0.1/224.0.0.2 that specify a Group Address=239.*.*.*);

[0626] The IPMS 120 and the Clients use Multicast Address=239.216.63.240to pass UDP packets using UDP Port=255.

[0627] In this scenario, the following initial handshake operations takeplace:

[0628] 1. IPMS 120 sends an IGMP V2 Membership Report (Destination IPAddress=39.216.63.240, Group Address=239.216.63.240);

[0629] 2. LAN Switch receives IGMP V2 Membership Report, forwards themessage, and adds the IPMS 120 to the Group, the 239.216.63.240multicast being used for multicast control messages;

[0630] 3. Gateway Router does not forward the administratively scopedmembership report to the Internet;

[0631] 4. Client H sends an IGMP V2 Membership Report (Destination IPAddress=239.216.63.240, Group Address=239.216.63.240);

[0632] 5. Access Switch/Router #1 forwards IGMP V2 Membership Report toLAN Segment#1 (assuming it has no other interfaces in GroupAddress=239.216.63.240);

[0633] 6. LAN Switch receives IGMP V2 Membership Report, forwards themessage, and adds Client H to the Group;

[0634] 7. Gateway Router does not forward the administratively scopedmembership report to the Internet;

[0635] 8. IPMS 120 receives IGMP V2 Membership Report, the239.216.63.240 multicast being used for multicast control messages;

[0636] 9. Client H sends an IGMP V2 Membership Report (Destination IPAddress=239.216.63.248, Group Address=239.216.63.248);

[0637] 10. Access Switch/Router #2 forwards IGMP V2 Membership Report toRemote Backbone (assuming it has no other interfaces in GroupAddress=239.216.63.248);

[0638] 11. LAN Bridge forwards IGMP V2 Membership Report;

[0639] 12. Remote Router ignores the administratively scoped IGMP V2Membership Report;

[0640] 13. LAN Switch receives IGMP V2 Membership Report, forwards themessage, and enables transmission of 239.216.63.248 multicast to LANSegment #2;

[0641] 14. IPMS 120 receives IGMP V2 Membership Report and transmits239.216.63.248 multicast out NIC#2 and NIC#3 onto Filtered Streams 1 and2—the data payload of the 239.216.63.248 multicast includes the IRMS 120IP Address, and a test pattern;

[0642] 15. If LAN Switch is IGMP V2 enabled, it will forward239.216.63.248 multicast to LAN Segment #2 only. If it is not soenabled, then the 239.216.63.248 multicast data will be forwarded toboth LAN Segment #1 and LAN Segment #2;

[0643] 16. LAN Bridge forwards the 239.216.63.248 multicast data;

[0644] 17. Access Switch/Router #2 forwards 239.216.63.248 multicast toClient H only;

[0645] 18. Remote Router ignores 239.216.63.248 multicast data;

[0646] 19. Client H receives the IPMS 120 IP Address and test patternand then sends an IGMP Leave Group (Destination IP Address=224.0.0.2,Group address=239.216.63.248);

[0647] 20. Access Switch/Router #2 receives IGMP Leave Group, verifiesit has no other interfaces in Group Address=239.216.63.248 (using IGMPQuery), forwards IGMP Leave Group to LAN Bridge, and immediately stopsforwarding the 239.216.63.248 multicast to Client H;

[0648] 21. LAN Bridge forwards the IGMP Leave Group command;

[0649] 22. Remote Router ignores the administratively scoped IGMP LeaveGroup command;

[0650] 23. LAN Switch receives IGMP Leave Group and forwards themessage. If it is IGMP V2 enabled, it will verify it has no other LANSegment #2 Clients in Group address=239.216.63.248 (using IGMP Query),and will immediately stop transmission of the 239.216.63.248 multicastto LAN Segment #2;

[0651] 24. IPMS 120 receives the IGMP Leave Group command, verifies ithas no other Clients in Group Address=239.216.63.248, and immediatelystops transmission of the 239.216.63.248 multicast data;

[0652] 25. Client H sends a UDP packet (Destination IPAdress=128.0.0.255, Port=255) to the IPMS 120;

[0653] 26. Access Switch/Router #2 forwards a UDP packet to the backboneof the remote ISP;

[0654] 27. LAN Bridge forwards the IGMP V2 Membership Report;

[0655] 28. Remote Router ignores the administratively scoped IGMP V2Membership Report;

[0656] 29. LAN Switch forwards the UDP packet to the IPMS 120 controlstream (NIC #1);

[0657] 30. IPMS 120 receives UDP packet and sends UDP packet response(Destination IP Address=128.0.0.1, Port=255) from NIC #1;

[0658] 31. LAN Switch forwards the UDP packet to the LAN Segment #2since the packet is addressed to Client H;

[0659] 32. Access Switch/Router #2 forwards UDP packet to Client H;

[0660] 33. Client H receives UDP packet.

[0661] The following operations occur when Client H joins MulticastGroup 239.216.0.8:

[0662] 34. Client H sends an IGMP V2 Membership Report (Destination IPAddress=239.216.0.8, Group Address=239.216.08);

[0663] 35. Access Switch/Router #2 forwards IGMP V2 Membership Report toRemote Backbone (assuming it has no other interfaces in GroupAddress=239.216.0.8);

[0664] 36. LAN Bridge forwards IGMP V2 Membership Report;

[0665] 37. Remote Router ignores the administratively scoped IGMP V2Membership Report;

[0666] 38. LAN Switch receives IGMP V2 Membership Report and forwardsthe message. If it is IGMP V2 enabled, it will enable transmission of239.216.0.8 multicast to LAN segment #2;

[0667] 39. IPMS 120 receives the IGMP V2 Membership Report and transmitsthe 239.216.0.8 multicast through NIC#3 onto Filtered Stream #2;

[0668] 40. LAN Switch forwards 239.216.0.8 multicast to LAN Segment #2only;

[0669] 41. LAN Bridge forwards the 239.216.0.8 multicast data;

[0670] 42. Access Switch/Router #2 forwards 239.216.0.8 multicast datato Client H only;

[0671] 43. Remote Router ignores 239.216.0.8 multicast data;

[0672] 44. Client H receives 239.216.0.8 multicast.

[0673] The following query operations also take place to ensure thatunnecessary multicast data is not transmitted over any LAN:

[0674] 45. Access Switch/Router #2 sends IGMP Group-Specific Query(Destination IP Address=239.216.0.8.Group Address=239.216.0.8) to ClientH;

[0675] 46. If Access Switch/Router #2 receives an IGMP V2 MembershipReport (Destination IP Address=239.216.0.8, Group Address=239.216.0.8),do nothing;

[0676] 47. If there is no Membership Report, then Access Switch/Router#2 sends an IOMP Leave Group command (Destination IP Address=224.0.0.2,Group Address=39.216.0.8) to the backbone of the remote ISP andimmediately stops forwarding the 239.216.0.8 multicast data to Client H;operations then proceed from Step 63 below;

[0677] 48. IPMS 120 sends UDP packet (Destination IPAddress=239.216.63.240, Port=255) from NIC #1;

[0678] 49. If LAN Switch is IGMP V2 enabled, it will forward the packetto all interfaces currently monitoring the 239.216.63.240 stream if itis not IGMP V2 enabled, the packet will be forwarded to all LANinterfaces

[0679] 50. Access Switch/Routers forwards the packet to all Clientslistening to the 239.216.63.240 stream;

[0680] 51. Client H responds with a UDP packet (Destination IPAddress=239.216.63.240, Port=255);

[0681] 52. Access/Switch Router #2 forwards the packet to the backboneof the remote ISP;

[0682] 53. LAN Bridge forwards packet;

[0683] 54. Remote Router ignores packet;

[0684] 55. The LAN Switch forwards packet to the IPMS 120 NIC #1;

[0685] 56. If IPMS 120 does not receive a UDP response, then itimmediately stops forwarding the 239.216.0.8 to all Clients (group isleft due to no response). If the LAN Switch is IGMP V2 enabled, thefollowing operations will take place:

[0686] 57. LAN Switch sends IGMP Group-Specific Query (Destination IPAddress=239.216.0.8, Group Address=239.216.0.8) to LAN Segment #2;

[0687] 58. LAN Bridge forwards IGMP Group-Specific Query;

[0688] 59. If LAN Switch receives an IGMP V2 Membership Report(Destination IP Address=239.216.0.8, Group Address=239.216.0.8), then donothing;

[0689] 60. If there is no Membership Report, then LAN Switch immediatelystops transmission of 239.216.0.8 multicast to LAN Segment #2 (group isleft due to no response).

[0690] The following operations take place when Client H leavesMulticast Group 239.216.0.8:

[0691] 61. Client H sends an IGMP Leave Group command (Destination IPAddress=224.0.0.2, Group Address=239.216.0.8);

[0692] 62. Access Switch/Router #2 receives the IGMP Leave Groupcommand, verifies it has no other interfaces in GroupAddress=239.216.0.8 (using IGMP Query), forwards the IGMP Leave Group tothe backbone of the remote ISP, and immediately stops forwarding the239.216.0.8 multicast data to Client H;

[0693] 63. LAN Bridge forwards IGMP Leave Group command;

[0694] 64. Remote Router ignores the administratively scoped IGMP LeaveGroup command;

[0695] 65. LAN Switch receives the IGMP Leave Group command and forwardsthe message; if it is IGMP V2 enabled, it verifies it has no other LANSegment #2 Clients in Group Address=239.216.0.8 (using IGMP Query), andimmediately stops transmission of 239.216.0.8 multicast to LAN Segment#2;

[0696] 66. IPMS 120 receives the IGMP Leave Group command, verifies ithas no other Clients in Group Address=239.216.0.8. and immediately stopstransmission of the 39.216.0.8 multicast.

[0697] The following termination handshake operations also take place:

[0698] 67. Client H sends a UDP packet (Destination IPAddress=128.0.0.255, Port=255) to the IPMS 120;

[0699] 68. Access Switch/Router #2 forwards the UDP packet to thebackbone of the remote ISP;

[0700] 69. LAN Bridge forwards the packet;

[0701] 70. Remote Router ignores the packet;

[0702] 71. LAN Switch forwards the packet to IPMS 120 NIC #1;

[0703] 72. IPMS 120 receives the UDP packet and sends a UDP packet(Destination IP Address=128.0.0.1, Port=255) to Client H;

[0704] 73. LAN Switch forwards the packet to LAN Segment #2 only;

[0705] 74. LAN Bridge forwards the packet;

[0706] 75. Access Switch/Router #2 forwards the packet to Client H only;and

[0707] 76. Client H receives the UDP packet.

[0708] If remote clients join “normal” multicast groups through theremote router, the 224.0.0.1 and 224.0.0.2 IGMP V2 messages will bebridged to the LAN Switch. The LAN Switch will forward the IGMP messagesthrough LAN segment #2 to the IPMS 120. The IPMS 120 will ignore themessages issued for a non-existent stream.

[0709]FIG. 27 shows a basic ISP configuration. The Internet is connectedto an internal 10 BaseT LAN. This internal LAN has a local file serverthat is used for locally served Web pages. Also on this LAN is connecteda remote access server (modem pool) which is used to Connect the ISPcustomers via the LEC (local exchange carrier—the local phone company)to the Internet.

[0710]FIG. 28 shows how this ISPO grows to serve more customers. A layer3 switch is added to the Internal ISP LAN. This LAN is usuallyinterconnected by 100 BaseT added to the internal ISP LAN. This LAN isusually interconnected by 100 BaseT or FDDI transmission technology. Theswitch is used to interconnect multiple 10 BaseT LAN segments to the ISPLAN. Each of these segments have multiple remote access servers that areused to connect users to the Internet.

[0711]FIG. 29 shows how broadband multimedia data is inserted into anISP using the ideas described in this application. This configurationtakes advantage of current ISP architectures. Many ISP's today haveevolved over time as shown in FIG. 27 and FIG. 28. They started with oneremote access router serving a few customers (FIG. 27) and have expandedto multiple remote access routers (FIG. 28). FIG. 29 shows the additionof multiple satellite receivers that receive multicast data.

[0712] In this configuration, the Layer 3 IP switch performs severalfunctions. The first function is to connect the proper multicast streamform the appropriate satellite receiver to the appropriate LAN segments.This requires the switch to implement the IP Multicast Protocol (RFC1112).

[0713] The second function is to connect the proper Internet traffic tothe appropriate LAN segment.

[0714] The third function of the Layer 3 switch is to perform the IOMPquerier function as specified in RFC 1112.

[0715] If the existing Layer 3 switch meets the above requirements, thenit can be used. If not, then the ISP must upgrade the switch with onethat meets these requirements. The commercially available HP800T switchis one example of such a layer 3 multicast enabled switch.

[0716] Such a configuration has the advantage of simplicity since thesatellite receiver only needs to strip the HDLC (or other) encapsulationfrom the incoming data and electrically convert the data to the ethernetformat. It does not need to have any knowledge of IP multicastingprotocols.

[0717] Enhancements that could be incorporated in the receiver could bemulticast address translation and data de-scrambling. In this case, thereceiver must understand the IP multicasting protocol to perform theseappropriate functions.

[0718]FIG. 30 illustrates the layout of an exemplary, traditional webpage 800 suitable for use in the present multicast system. Asillustrated, the web page 800 includes a video display window 800 thataccepts and displays a video data stream from the broadcasttransmission. External to the video display window 800, text, andgraphic content relating to the content of the video is displayed. Suchcontent can be provided in the broadcast transmission itself, over thebackbone of the Internet, or from storage at the ISP.

[0719] The web page 800 is also provided with a plurality of baud rateselection buttons 810,815, 820, and 825. Each button corresponds to abaud rate of a broadcast video stream, each stream having the samemultimedia content. For example, button 810 may correspond totransmission of the media content for the display window 800 at 14.4K.Similarly, buttons 815, 820, and 825 may correspond to baud rates of28.8 K, 56.6 K, and 1.5 MB, respectively. This allows the client toselect a baud rate for the video transmission rate that is suited to hissystem.

[0720] The web page provides substantial information and versatility tothe user. The user may be presented with a substantially continuous flowof video information while concurrently having text and otherinformation presented to him that may or may not be related to the videoto allow the user to select other web pages, audio information, furthervideo content, etc. These further selections may relate to theparticular topic, product, etc., provided in the video content. The usermay be given an option to select multiple video channels that may besupplied concurrently. The user is provided with a substantial number ofchannels to choose from, thereby allowing the user to select the desiredvideo content.

[0721] The web page needed not necessarily be provided with buttons forthe selection of baud rate. Rather, a software plug-in for the webbrowser used by the client may be used to automatically join theappropriate multicast group depending on the data rate at which theclient communicates with the ISP. In such instances, the plug-insoftware first detects the data rate at which the client iscommunicating with the Internet service provider. When a client wishesto view a particular video stream content, the software compares thisdetected data rate against a table of different data rates for the samecontent, each data rate corresponding to a unique multicast Groupaddress. The software joins the client to the multicast group having themaximum data rate that does not exceed the data rate at which thesoftware detected the communications between the client and the Internetservice provider.

[0722] An exemplary embodiment of software that may be used for thispurpose is set forth in an “Appendix A”, filed with related applicationSer. No. 08/969,164, now U.S. Pat. No. 6,101,180, the entire contents ofwhich is incorporated by reference herein. Appendix A includes listingsof software source code in C++ for automatically detecting the baud rateat which the client is connected to the system and selecting the propermulticast join group.

[0723] Numerous modifications can be made to the foregoing systemwithout departing from the spirit and scope of the various inventiveaspects of this invention as set forth in the appended claims.Therefore, it is the intention of the inventors to encompass all suchchanges and modifications that fall within the scope of the appendedclaims.

What is claimed is:
 1. A system for delivering streaming audio from anorigination point to plural remote users coupled to a congested computernetwork while reducing the effect of network congestion on thetimeliness and/or quality of said streaming audio delivery, the deliverysystem comprising: at least one out-of-network connection that transmitsthe streaming audio from the origination point to plural intermediatenodes disposed within the congested network and thereby bypasses atleast some of the congestion on the network; and a streaming audioforwarding arrangement at each of said intermediate nodes, saidforwarding arrangement transmitting the streaming audio to the pluralremote users over the congested network via a two-way interactivenetwork connection.
 2. The delivery system of claim 1 wherein theout-of-network connection carries the streaming audio as a one-way datastream.
 3. The delivery system of claim 1 wherein each intermediate nodeincludes a satellite receiver.
 4. The delivery system of claim 1 whereineach said intermediate node injects the streaming audio into the networkwithout providing to the origination point substantial TCP confirmationof delivery.
 5. The delivery system of claim 1 wherein the streamingaudio includes a plurality of audio channels, and the out-of-networkconnection simultaneously sends the plurality of audio channels to eachof the intermediate nodes.
 6. The delivery system of claim 1 wherein theout-of-network connection includes a satellite uplink.
 7. The deliverysystem of claim 6 wherein the satellite uplink is one-way.
 8. Thedelivery system of claim 1 wherein the origination point is adapted tobroadcast to at least one extraterrestrial satellite an uplink carriercarrying streaming audio data packets, the extraterrestrial satelliteproviding the streaming audio data packets on a downlink carriercomprising the out-of-network connection.
 9. The delivery system ofclaim 1 wherein the congested network comprises the Internet.
 10. Thedelivery system of claim 1 wherein the intermediate nodes each providetwo-way Internet access to remote Internet users.
 11. The deliverysystem of claim 1 wherein each said intermediate node includes ademultiplexer adapted to recover said streaming audio from saidout-of-network connection, and a router adapted to receive and routesaid streaming audio over the congested network.
 12. The delivery systemof claim 11 wherein the out-of-network connection has a predeterminedguaranteed reserved bandwidth that is sufficient to simultaneously carryplural streaming audio channels substantially in real time.
 13. Thedelivery system of claim 1 wherein the origination point is adapted toprovide plural audio streaming channels to said out-of-networkconnection in streaming IP format; and each said intermediate networknode is adapted to provide access to said streaming IP format channelsto each of said plurality of remote users.
 14. The delivery system ofclaim 13 wherein the streaming IP format comprises a one-way data streamand the out-of-network connection provides a one-way satellite link. 15.An audio media distribution system for distributing audio content toInternet users accessing the Internet, the audio distribution systemcomprising: a) a satellite uplink; b) an audio delivery system incommunication with said satellite uplink and providing at least oneaudio data stream to said uplink; c) the satellite uplink providing atleast one dedicated digital communications channel of predeterminedallocated bandwidth, said allocated bandwidth being sufficient totransmit said audio data stream substantially in real time; d) aplurality of remote Internet access gateways; e) a plurality of remotesatellite downlink systems, each of said remote satellite downlinksystems being in communication with one of said remote Internet accessgateways; f) each said remote satellite downlink systems comprising atleast a satellite receiver/demultiplexer and an Internet router, saidreceiver/demultiplexer and Internet router cooperatively recovering saidaudio stream from said satellite channel and providing access to saidaudio stream substantially in real time to one or more Internet users.16. The audio media distribution system of claim 15 wherein: (i) theaudio delivery system provides a plurality of audio data streams to saidsatellite uplink, and (ii) the predetermined allocated bandwidth of saidchannels is sufficient to transmit said plurality of audio data streamssubstantially in real time.
 17. The audio media distribution system ofclaim 15 wherein: (i) the audio delivery system provides a plurality ofaudio data streams to said satellite uplink in streaming IP format, and(ii) the remote satellite downlink system provides access to IP formatstreaming audio data to one or more Internet users.
 18. The audio mediadistribution system of claim 17 wherein the IP format streaming audiodata is provided as a unidirectional data stream and the satelliteuplink is a unidirectional digital communications link.
 19. The audiomedia distribution system of claim 15 wherein: (i) the audio deliverysystem provides said audio content to said satellite uplink in streamingIP format, and (ii) the remote satellite downlink system provides IPformat streaming audio data to each of a plurality of remote Internetusers.
 20. The media distribution system of claim 15 wherein the IPformat streaming audio data is provided as a unidirectional data stream.21. A method of streaming digital data comprising one or more channelsof audio content to a plurality of Internet points of presence of an ISPor other entity, comprising the steps of: a) predetermining an amount ofbandwidth required to stream one or more channels of audio content tosaid points of presence substantially in real time; b) reserving saidamount of bandwidth of a digital data communications medium that issubstantially separate from the Internet backbone; and c) transmitting,substantially in real time, one or more channels of streaming audiocontent through said digital data communications medium to saidplurality of points of presence.
 22. The method of claim 21 wherein themethod further includes the step of: d) providing, at each said pointsof presence, substantially real time access to said one or more channelsof streaming audio content for one or more Internet users whom haveaccess to the Internet through said points of presence.
 23. The methodof claim 22 wherein the transmitting step (c) includes transmitting saidone or more channels of audio content without receiving substantial TCPconfirmation of delivery from said points of presence.
 24. The method ofclaim 23 wherein the transmitting step (c) includes streaming said oneor more channels of audio content within a one-way data formattransmitted through an extraterrestrial satellite link.
 25. The methodof claim 22 wherein the transmitting step (c) includes streaming saidone or more channels of audio content within a one-way data formattransmitted through an extraterrestrial satellite link.
 26. The methodof claim 21 wherein the transmitting step (c) includes transmitting saidone or more channels of audio content without receiving substantial TCPconfirmation of delivery from said points of presence.
 27. The method ofclaim 21 wherein the transmitting step (c) includes streaming said oneor more channels of audio using a one-way data transmission format. 28.A method of multicasting multimedia information including at least audiocontent to a user apparatus accessing the Internet through a remoteInternet point of presence, the method comprising the steps of: a)placing the multimedia information in an IP protocol to generate IPmulticast multimedia information; b) transmitting the IP multicastmultimedia information to the remote Internet point of presence throughone or more one-way transmission bandwidth portions separate from one ormore two-way Internet traffic bandwidth portions; wherein the multimediainformation includes a plurality of audio channels and wherein saidaudio channels are allocated to one or more reserved channel-sufficientportions of said one or more one-way transmission bandwidth portions,whereby each of said audio channels is multicast to the remote Internetpoint of presence without interruption due to a separate audio channelbeing transmitted through said one or more one-way transmissionbandwidth portions.
 29. The method of claim 28 wherein the method alsoincludes step c: transmitting additional IP protocol information to theremote Internet point of presence through two-way Internet trafficbandwidth for forwarding of both the IP multicast multimedia informationand the additional IP protocol information to the user apparatus througha two-way connection between the remote Internet point of presence andthe user apparatus.
 30. The method of claim 29 wherein at least one userapparatus has multimedia output capabilities and simultaneously playsaudio content provided by the IP multicast multimedia information anddisplays viewable image information provided by the additional IPprotocol information.
 31. The method of claim 30 wherein the viewableimage information includes at least a portion of an interactive webpage, whereby a user may interact with the viewable information tomaneuver through at least a portion of an Internet backbone.
 32. Amethod of bypassing an Internet backbone and multicasting digital data,including at least audio data, through a remote Internet point ofpresence from which remote, distal user apparatus receive Internetcontent, the method comprising the steps of: a) placing the digital datain an IP multicasting protocol to generate IP multicast data; b)streaming the IP multicast data, substantially comprising one-way dataflow, from a transmission site to the remote Internet point of presencethrough one or more reserved bandwidth portions substantially reservedto the streaming IP multicast data and associated information; whereinthe audio data includes a plurality of audio channels and wherein saidaudio channels are allocated to one or more reserved channel-sufficientportions of the one or more reserved bandwidth portions, whereby each ofsaid audio channels is multicast to the remote Internet point ofpresence without interruption due to another video channel beingtransmitted through said one or more reserved bandwidth portions. 33.The method of claim 32 wherein the method also includes step (c):transmitting additional IP protocol audio data to the remote Internetpoint of presence through one or more additional bandwidth portions forforwarding of both the IP multicast data and the additional IP protocoldata to the remote user apparatus through TCP/IP connections between theremote point of presence and the remote user apparatus.
 34. The methodof claim 33 wherein a plurality of user apparatus each have multimediaoutput capability which simultaneously plays audio provided by the IPmulticast data and displays other viewable image information provided bythe additional IP protocol data.
 35. The method of claim 34 wherein theviewable image information includes at least a portion of an interactiveweb page, whereby a user may interact with the viewable information tomaneuver through at least a portion of an Internet backbone.
 36. Amethod of multicasting digital data, including at least audio digitaldata, to user apparatus accessing an Internet connection, the methodcomprising the steps of: a) placing the digital data in an IPmulticasting protocol to generate IP multicast data; b) streaming the IPmulticast data from a transmission site to a remote Internet point ofpresence through one or more portions of bandwidth substantiallydedicated to the streaming IP multicast data and associated information;and c) multicasting at least a portion of the IP multicast data from theremote Internet point of presence for delivery to at least one receivingInternet user's apparatus distal from the remote Internet point ofpresence; wherein the audio digital data includes a plurality of audiochannels and wherein said audio channels are allocated to one or morereserved channel-sufficient portions of the one or more portions ofbandwidth, whereby each audio channel is multicast to the remoteInternet point of presence without interruption due to another audiochannel being transmitted through said one or more portions ofbandwidth.
 37. The method of claim 36 wherein said receiving Internetuser apparatus each include a video display with an audio output thatsimultaneously plays audio provided by the IP multicast data anddisplays other viewable image information provided to the usersapparatus by the remote Internet point of presence.
 38. The method ofclaim 37 wherein the viewable image information includes at least aportion of an interactive web page, whereby a user may interact with theviewable image information to maneuver through at least a portion of anInternet backbone.
 39. A method of distributing multicast audio contentto Internet user apparatus, the method comprising the steps of: a)transmitting IP protocol digital audio content to Internet userapparatus through two-way IP protocol bandwidth; and b) simultaneouslystreaming multicast content to Internet user apparatus through one ormore one-way reserved bandwidth portions bypassing the two-way IPprotocol bandwidth for reception by the Internet user apparatus inconjunction with the IP protocol content; wherein the multicast contentincludes a plurality of audio channels and said audio channels areallocated to one or more reserved channel-sufficient portions of the oneor more one-way bandwidth portions, whereby each audio channel ismulticast without interruption due to any other audio or video channelbeing transmitted through said one-way bandwidth portions.
 40. Themethod of claim 39 wherein the one-way bandwidth utilizes a connectionindependent of said two-way IP protocol Internet bandwidth.
 41. Themethod of claim 39 wherein said two-way IP protocol Internet bandwidthincludes the Internet backbone segment.
 42. The method of claim 40wherein said two-way IP protocol Internet bandwidth includes an Internetbackbone segment.
 43. The method of claim 39 wherein a plurality of theuser apparatus each have an audio and video output capabilities forsimultaneously outputting audio provided by the multicast content anddisplaying additional viewable image information provided by the IPprotocol content.
 44. A method of delivery of at least audio content toremote user computing apparatus, the method comprising the steps of: a)placing at least the audio content in a multicasting protocol togenerate audio multicast content; b) streaming the audio multicastcontent to a local point of presence through one or more one or moretransmission bandwidth portions reserved for the audio content forsubsequent distribution to the remote user computing apparatus; whereinthe audio content includes a plurality of audio channels and whereinsaid audio channels are allocated one or more channel-sufficientsegments of the one or more transmission bandwidth portions, wherebyeach of said audio channels is streamed to the local point of presencewithout substantial interruption due to a separate audio channel beingtransmitted through the one or more transmission bandwidth portions. 45.The method of claim 44 wherein the one or more bandwidth portionsinclude satellite bandwidth.
 46. The method of claim 44 wherein themethod also includes the step of transmitting additional Internetprotocol information through TCP/IP Internet bandwidth portions forforwarding of both the audio content and the additional Internetprotocol information to the remote user computing apparatus.
 47. Themethod of claim 45 wherein the method also includes the step oftransmitting additional Internet protocol information through TCP/IPInternet bandwidth portions for forwarding of both the audio content andthe additional Internet protocol information to the remote usercomputing apparatus.
 48. The method of claim 47 wherein a plurality ofuser computing apparatus each have a audio output and video display thatsimultaneously plays audio provided by the audio content and additionalviewable image information provided by the additional Internet protocolinformation.
 49. The method of claim 28 wherein the one or more one-waytransmission bandwidth portions are included in a transmissionconnection independent of an Internet backbone segment.
 50. The methodof claim 29 wherein the one or more one-way transmission bandwidthportions are included in a transmission connection independent of anInternet backbone.
 51. The method of claim 30 wherein the one or moreone-way transmission bandwidth portions include wireless bandwidth. 52.The method of claim 32 wherein the one or more reserved bandwidthportions include wireless bandwidth.
 53. The method of claim 33 whereinthe one or more reserved transmission bandwidth portions includewireless bandwidth.
 54. The method of claim 34 wherein the one or morereserved bandwidth portions include satellite bandwidth.
 55. The methodof claim 35 wherein the one or more reserved bandwidth portions includesatellite bandwidth.
 56. The method of claim 36 wherein the one or moreportions of bandwidth include satellite bandwidth.
 57. The method ofclaim 37 wherein the one or more portions of bandwidth include satellitebandwidth.
 58. The method of claim 38 wherein the one or more portionsof bandwidth include satellite bandwidth.
 59. The method of claim 39wherein the one or more one-way reserved bandwidth portions includesatellite bandwidth.
 60. The method of claim 41 wherein the one or moreone-way reserved bandwidth portions include satellite bandwidth.
 61. Themethod of claim 44 wherein the one or more transmission bandwidthportions include satellite bandwidth.
 62. The method of claim 46 whereinthe one or more transmission bandwidth portions include satellitebandwidth.
 63. The method of claim 47 wherein the one or moretransmission bandwidth portions include wireless bandwidth.
 64. Themethod of claim 48 wherein the one or more transmission bandwidthportions include wireless bandwidth.